How to restrict variable (pointers) count to a single instance of an object ?

[freefighter]

Is there such a way to ensure that at a time just one variable
(pointer to ref type) is used to maintain the object. This is needed
for a multi-threded application where shared data should be used
properly.
In general I`ve done this by locking objects` fields using mutexes or
lock(){} mechanism, but this cann`t be done for CRL general types (as
collections) where from several places the data could be used by
different pointers ..
10x in advance

 

[Peter Duniho]

Is there such a way to ensure that at a time just one variable
(pointer to ref type) is used to maintain the object. This is needed
for a multi-threded application where shared data should be used
properly.

I'm not even clear on how this would work. Suppose you have a thread with
a reference to the instance. Then another thread goes to assign that
reference to its own variable. What happens to the original reference?
Is it set to "null"? Or what?

In general I`ve done this by locking objects` fields using mutexes or
lock(){} mechanism, but this cann`t be done for CRL general types (as
collections) where from several places the data could be used by
different pointers ..

Why can't you use mutexes or lock()? Other people do it just fine without
any trouble. What problem are you running into that prevents you from
doing that?

Pete

 

[Nicholas Paldino [.NET/C# MVP]]

In order to do this, you have to expose a class which has all the
methods of the object you want to synchronize access to and then forward all
the calls to the underlying instance. Each place where you forward a call,
you will need to place a lock statement around the call (preferably locking
on an object private to the class instance) so that you can synchronize
access.

 

[freefighter]

suppose we have

public class StorageType
{
// fields
private ArrayList m_SomeList = new ..
private static object m_Locker = new object();

// property
public ArrayList SomeList
{
get{ lock(m_Locker) { return m_SomeList;}}
set{ lock(m_Locker) { m_SomeList = value;}}
}

// other stuff
}


public class Test
{
public void Main()
{
StorageType storage = new StorageType();
// then we make several threads as follows
}

public void Method1(StorageType storage)
{
// Thread 1 Method
storage.SomeList.Sort() // example
}


public void Method2(StorageType storage)
{
// Thread 2 Method
stogare.SomeList.Add(...);
}

}

so according to my knowlegde, the lock() mechanism is locking the code
in the {} that follow it, so in this case
its about copying references to an instance of the storage object. to
if one thread is using the object by already set variable. so locking
just ensures that references to the object are done one by the time,
but after the pointer is returned, the lock is no longer in charge of
how the reference is used ..

in the example (up) if the Sort() method takes time, what happens if
method 2 tries to Add() asyncronously ??!

 

[Peter Duniho]

so according to my knowlegde, the lock() mechanism is locking the code
in the {} that follow it, so in this case
its about copying references to an instance of the storage object.

Yes, you have that correct.

to if one thread is using the object by already set variable. so locking
just ensures that references to the object are done one by the time,
but after the pointer is returned, the lock is no longer in charge of
how the reference is used ..

Yes, you're right. The code you posted doesn't keep the object locked
once the reference has been returned.

in the example (up) if the Sort() method takes time, what happens if
method 2 tries to Add() asyncronously ??!

Something bad, I'm sure.

There are a variety of ways to deal with the issue, all of which at the
core require you to ensure that you only have one thread accessing your
m_SomeList object at time. If there were a way to ensure that only one
reference to it existed at any given time, that would do the job, but
there's not really any way to do that. So instead you have to make sure
that operations on the object are synchronized with any other operation on
the object. ArrayList doesn't do this for you, so you have to do it
yourself.

As a start, allowing the object reference itself to escape your
StorageType class is just asking for trouble, because anyone can write
code that gets that reference does something to it. If you know the
object is going to be used from multiple threads, you need a single
"gatekeeper" that ensures that operations on the object are done in a
synchronized way. The suggestion Nicholas provided is one way to do this.

Pete