-----------------------------------------------------------
New Message on BDOTNET
-----------------------------------------------------------
From: SitaramanM
Message 1 in Discussion
Hi All Some time back there was a post regarding the Thread Synchronisation
fairness in the .Net Remoting
Model("http://groups.msn.com/BDotNet/general.msnw?action=get_message&mview=0&ID_Message=4827&LastModified=4675437351912727346";
by HarshPriya(August 18 2003)) which was as follows "I need a clarification on
.NET remoting. Consider using singleton
call for .NET remoting. When one thread is using the object the other
threads wait for the object to be released. When the thread releases the
object after getting the service, do the waiting threads get the object in
FIFO(queue) fashion or it random racing as its in OS level?
I did a search on the internet for how singleton is implemented.
Does it maintain a FIFO or its just OS level thread racing scenarios? But no
luck. If you could help me on this topic or give me some pointers, it would
be great." "it would be great if you could get me a solid
proof of working or article which says so it happens or are you 100% sure of
it? This is because I have to implement this in a real time critical project
where I do not want to take chances. In case if its not too sure that the
thread queuing is done, I am all the more ready to implement a FIFO with a
semaphore and stuff. Thanks a lot for your time and help" Basically what you are
talking about is nothing but Fair Thread Synchronisation . There were quite a few
replies to this post and one of them was a FIFO(by GAGS) and the other was "based on
thread priorities and time slice" by Rajesh Didnt give it much of a thought at that
time. came across a related article by Jeffrey Richter on this topic recently which
reminded me of the original post. As you had mentioned that you talked of a business
critical system, thought it worthwile to recall your post. The article talks about
the Synchronisation Fairness in the .Net platform and basically is about the TryEnter
method used for Thread Synchronisation in a scenario where multiple threads try to
access a method of a same instance. But logically the same should apply for the
Remoted SingleTon object also. Let me start by saying IT DEFINITELY IS NOT FIFO.
To keep things simple to explain lets first get into a normal local singleton object
access scenario and then build it from the remoting perspective. In a normal
situation if i have multiple objects accessing a single instance then i need to ensure
thread Synchronisation. In order to do tht i will typically use a Monitor Class(or
other similar mechanisms). So if multiple clients access a method call the first guy
who gets to the method call first acquires a lock onto the critical sectkion(section
in between the Monitor.Enter and Monitor.Exit) and then starts processing. in the
meantime the other threads keep waiting. The problem is in terms of "when one thread
is currently serviced, how are the other threads made to wait" To quote Jeffrey(he
talks of the TryEnter method but is valid in your context also) Internally, TryEnter
sleeps waiting for an owned object to become available. When the thread that owns the
object releases it, all waiting threads are awakened. Each of the waiting threads
loops around trying to gain ownership of the object again. One of the waiting threads
will become the owner and the other threads will go back to sleep. When a thread goes
back to sleep, it subtracts the amount of time that the thread has already slept from
the amount of time the caller specified to the TryEnter method. So, to the caller, it
looks like the thread is sleeping the correct amount of time. While TryEnter is not
buggy, it is not fair: It's entirely possible (and quite likely) that multiple threads
waiting to own an object will not be serviced in a first-in-first-out fashion. So, the
important thing for you to be aware of is that thread synchronization using the
Monitor cSo, the important thing for you to be aware of is that thread synchronization
using the Monitor class is not fair in the .NET Framework and there is no way to make
it fair. This means that if you have threads that are constantly trying to own an
object using a Monitor, it is possible that some threads will never gain ownership!
This also means that you should not use the Monitor if you are building an application
that tries to simulate some kind of real-world situation that involves a queue. For
example, you should not try to build a supermarket simulation where customers are
standing in line at a cash register trying to be serviced on a first-come-first-serve
basis and you want to see how many customers can be serviced per hour. If you use a
Monitor for this, the simulation will be broken because it would allow customers to
jump in front of other customers in the line I wrote a sample program and checked
and found that in the case of simple Monitor.Enter also. The order in which the
threads enter a function is different from the order in which they acquire a lock
inside the function. What i mean is that if i have a function fn1 internally in
the function i use Monitor.Enter threads 0 1 2 3 4 5 6 7 8 9 enter the function in
that order Assume Thread 0 hits the Monitor.Enter First threads 1 2 3 4 5 6 7 8 9 hit
the Monitor.Enter in that order and are made to wait NOW after the Thread 0 executes
Monitor.Exit, it is not necessary that Thread 1 will get access. Any thread can get
access(for e.g. Thread 8 could acquire a lock and enter making Threads 1 2 3 4 5 6 7
9 wait...). This i have tested and found to be true And as to your observation
"This is because I have to implement this in a real time critical project where I do
not want to take chances. In case if its not too sure that the thread queuing is done,
I am all the more ready to implement a FIFO with a semaphore and stuff. Thanks a lot
for your time and help" you are again in for trouble coz The CLR manages memory via
garbage collection. When the CLR wants to start a garbage collection, it will
determine which threads are currently executing managed code and which threads are
currently executing unmanaged code. After making this determination, the CLR will
suspend the threads executing managed code. Threads that are currently executing
unmanaged code will self-hijack themselves when they attempt to return back to managed
code. There is a small window of time where a thread is currently in managed code, the
CLR thinks it needs to suspend this thread, and then the thread calls into the
unmanaged Win32 WaitForSingleObject or WaitForMultipleObjects functions and while in
one of these functions, the CLR suspends the thread.
When Windows suspends a thread, it stops the thread from waiting for any thread
synchronization object. Later, when the thread is resumed, all the suspended threads
race back to wait on the object that it was waiting on before it got suspended. This
means that threads are not guaranteed to gain ownership of an object on a
first-in-first-out basis. Since a garbage collection can start at any time (and cannot
be prevented), the architecture of the CLR just doesn't support fair thread
synchronization � period. In addition, all managed wait methods (such as WaitHandle's
WaitOne, WaitAll, and WaitAny methods) put the calling thread into an alertable state,
which can also force a thread to stop waiting on an object and to re-queue its wait in
a different order.
If you are building an application that absolutely requires fair thread
synchronization, you should not use the .NET Framework at all. If your application's
threads require synchronized access to resources only periodically, then the CLR's
unfairness will most likely not be a problem for your application. In fact, most
applications will run fine without fair thread synchronization but, at least, you
should be aware of this issue. Here there is no mention of Remoting. Nevetheless,
the same technique and principles will apply to remoting also and as per my test
program modified to a remoting scenario, i found the results to be the same as it was
in the local object access scenario, i.e. NO FIFO... For the complete article check
out Jeff's "Thread Synchronization Fairness in the CLR " at
http://www.wintellect.com/resources/redirect.asp?url=http://www.codeguru.com/net_general/ThreadSynchFair.html
hth would appreciate any comments from the group on the same regards, sr
-----------------------------------------------------------
To stop getting this e-mail, or change how often it arrives, go to your E-mail
Settings.
http://groups.msn.com/BDotNet/_emailsettings.msnw
Need help? If you've forgotten your password, please go to Passport Member Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help
For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact
If you do not want to receive future e-mail from this MSN group, or if you received
this message by mistake, please click the "Remove" link below. On the pre-addressed
e-mail message that opens, simply click "Send". Your e-mail address will be deleted
from this group's mailing list.
mailto:[EMAIL PROTECTED]
