Stateless Objects & Multiple Threads

S

Steve - DND

I've seen many threads on Google about questions regarding stateless
classes, and thread synchronization. However, either I am dense, or I have
just not found the right thread, but I'm still not clear on how it all
works. I understand that if I have a static member variable such as a
collection, then I need to lock those operations as below, correct?

public class StaticClass {
private static HashTable m_Hash = new HashTable();

public static void AddToHash(string key, string value) {
lock (m_Hash) {
m_Hash.Add(key, value);
}
}
}

What about in the instance below, where there are variables local only to
the function being called. Do I need to worry about interference from other
threads?

public class StaticClass {
private static HashTable m_Hash = new HashTable();

public static void GetHash(int id) {
HashTable hash = null;
if (id > 0) {
hash = StaticClass.GetDataByID(id);
}
return hash;
}
}

Do I need to worry about locking the HashTable in that instance or is it
playing in it's own sandbox at this point? What if 2 or more users attempt
to call StaticClass.GetHash(id) at the same time? Will there be any
interference or waiting that takes place, or does each user get their own
little version of the function to run? This confusion mostly stems from the
belief(my belief) that stateless objects are just one instance of a class
waiting for calls, and that only one user could access a given function at
any time, but many of the posts I have read seem to indicate otherwise.

Also if anyone knows where I can find any good articles or books on the
underlying nature of how the CLR works it would be really appreciated. I
would love to find out how the whole system really ticks.

Thanks,
Steve
 
F

Fergus Cooney

Hi Steve,

As you don't show what GetDataByID does, it's a bit hard to answer specifically about
that.

Generally, when you are thinking about threading and what goes on, think
in terms of the two executing right on top of each other - separated by only a
single bytecode in the IL. Whichever is in the lead has the other one breathing
down its neck but that thread may take the lead at any moment, and lose it in
the next. They can follow each other anywhere unless the second is stopped
at a gate (lock).

Thus access to anything that is in the scope of both has to be guarded, such
as with the lock on m_Hash. This isn't the case with local variables because
each thread has its own stack. But! If these variables are object references
and the referenced object in visible to both threads, locking is again required.

I suspect that the HashTable returned by GetDataByID would be just
such an object and a guard would be useful.

Regards,
Fergus
 
S

Steve - DND

As you don't show what GetDataByID does, it's a bit hard to answer specifically about
that.

I suspect that the HashTable returned by GetDataByID would be just
such an object and a guard would be useful.

GetDataByID was just a magical function I made up when I posted. In reality
this would most likely be a call to the data layer to return a DataReader,
DataTable, or maybe a HashTable of output variables for a stored
procedure(in which case I would be instantiating a new hash table in that
function, and then populating it with the output values before returning
it).

So in the case I listed above, I would not need to worry about locking that
HashTable since it is created indepently on each thread with each call,
correct?

Thanks,
Steve
 
F

Fergus Cooney

Hi Steve,

Yes, if the items are unique to each thread they'll be fine - it's only shared
stuff that you need worry about. And, I should have mentioned, when you
have writing to the object involved. 'Simultaneous' reading is fine because
the data isn't changing.

How magical is GetDataByID ? Can I do :-
GetDataByID ("Make me fabulously rich")

;-)

Regards,
Fergus
 
F

Fergus Cooney

|| > How magical is GetDataByID ? Can I do :-
|| > GetDataByID ("Make me fabulously rich")
||
|| Unfortunately that's a v2.0 feature.

LOL

Ah well, the hard way then. ;-))
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top