Monitor unblock priority

[vooose]

Suppose execution of a particular thread T1 hits

Monitor.Enter(o bj);
//critical section

and blocks at the first line. (ie someone else is in the critical
section) Now suppose more threads T2, T3... try to enter the critical
section and are blocked.

What is the order that the threads get to enter the critical section?
I'm hoping its

T1, T2, T3...

If not, is there any (easy) way to guarantee the thread that blocked
first gets to enter the CS next?
--
Wal
http://www.vooose.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Willy Denoyette [MVP]]

Inline ***

Willy.

"vooose" <no****@microso ft.com> wrote in message
news:ut******** ******@TK2MSFTN GP14.phx.gbl...

Suppose execution of a particular thread T1 hits

Monitor.Enter(o bj);
//critical section

and blocks at the first line. (ie someone else is in the critical
section) Now suppose more threads T2, T3... try to enter the critical
section and are blocked.

What is the order that the threads get to enter the critical section?
I'm hoping its

T1, T2, T3...
*** No, there is no way to hope for a FIFO fashion in thread scheduling in
..NET.
If not, is there any (easy) way to guarantee the thread that blocked
first gets to enter the CS next?
*** No, there is no way at all. What's more, thread "fairness" is not
guaranteed in .NET. That means that it's possible, when you have multiple
threads that are constantly trying to take ownership of an object, that some
thread(s) will never get serviced at all.

--
Wal
http://www.vooose.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Mohamoss]

Hi
I have been searching but couldn't find any article or document that says
it is implemented that way . but you can use semaphore objects or at worst
case build your own queue where blocked threads check in and out.
Mohamed Mahfouz
Developer Support Engineer
ITWorx on behalf of Microsoft EMEA GTSC

[vooose]

Willy, thanks for your replies.

I have thought of perhaps a way to guarantee the order of execution, not
using monitors. Instead of

Monitor.Enter(o bj);

and block subsequent threads, you do (pseudo here)

myArrayList.Add (Thread.Current Thread);
while(myArrayLi st[0] != Thread.CurrentT hread)
Thread.Sleep(10 );

//got past loop, do critucal stuff

myArrayList.Rem ove(Thread.Curr entThread);

Naturally the ArrayList would be made thread safe.

Any thoughts there?

Also I was wondering if you could answer one more question re: Monitors.
When we do

Monitor.Enter(o bj);

What happens if the Thread calls sleep? Naturally I would expect the
other threads to be locked out until the thread wakes up and calls Exit(
) but I'm not sure if this is what is guaranteed to happen.
--
Wal
http://www.vooose.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jon Skeet [C# MVP]]

vooose <no****@microso ft.com> wrote:

I have thought of perhaps a way to guarantee the order of execution, not
using monitors. Instead of

Monitor.Enter(o bj);

and block subsequent threads, you do (pseudo here)

myArrayList.Add (Thread.Current Thread);
while(myArrayLi st[0] != Thread.CurrentT hread)
Thread.Sleep(10 );

//got past loop, do critucal stuff

myArrayList.Rem ove(Thread.Curr entThread);

Naturally the ArrayList would be made thread safe.

Any thoughts there?
Yes - it's nastily inefficient, as you could have lots of threads which
end up taking most of the time calling Sleep. Instead, use a monitor
and Wait on it, then call NotifyAll on the monitor when you come out of
the appropriate block. (There's a bit more to it that that, of course,
but that's the relevant bit.)
Also I was wondering if you could answer one more question re: Monitors.
When we do

Monitor.Enter(o bj);

What happens if the Thread calls sleep? Naturally I would expect the
other threads to be locked out until the thread wakes up and calls Exit(
) but I'm not sure if this is what is guaranteed to happen.

Yes. Calling Thread.Sleep doesn't release any monitors. Calling
Monitor.Wait releases the monitor you wait on.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Willy Denoyette [MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

vooose <no****@microso ft.com> wrote:

I have thought of perhaps a way to guarantee the order of execution, not
using monitors. Instead of

Monitor.Enter(o bj);

and block subsequent threads, you do (pseudo here)

myArrayList.Add (Thread.Current Thread);
while(myArrayLi st[0] != Thread.CurrentT hread)
Thread.Sleep(10 );

//got past loop, do critucal stuff

myArrayList.Rem ove(Thread.Curr entThread);

Naturally the ArrayList would be made thread safe.

Any thoughts there?

Yes - it's nastily inefficient, as you could have lots of threads which
end up taking most of the time calling Sleep. Instead, use a monitor
and Wait on it, then call NotifyAll on the monitor when you come out of
the appropriate block. (There's a bit more to it that that, of course,
but that's the relevant bit.)

Jon,

And what if the CurrentThread never equals the myArrayList[0] thread?
This what I meant in my previous reply, don't count on it, the CLR doesn't
guarantee "fairness", so it's possible the thread your waiting for never get
serviced.
AFAIK there is no solution to this in managed world.

Willy.

[vooose]

Eventually CurrentThread would have to equal myArrayList[0] (all other
things working correctly).

Eventually thread T2 that is waiting on T1 to remove itself from
myArrayList so T2 is now == myArrayList[0].

When T2 wakes up from Thread.Sleep(10 ); it entera the CS.
How could T2 not be guaranteed that execution sequence?

To me that is like saying any given thread may never execute one line of
code because the OS never schedules that thread to run!

--
Wal
http://www.vooose.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Willy Denoyette [MVP]]

"vooose" <no****@microso ft.com> wrote in message
news:OR******** *****@TK2MSFTNG P11.phx.gbl...

Eventually CurrentThread would have to equal myArrayList[0] (all other
things working correctly).

Eventually thread T2 that is waiting on T1 to remove itself from
myArrayList so T2 is now == myArrayList[0].

When T2 wakes up from Thread.Sleep(10 ); it entera the CS.
How could T2 not be guaranteed that execution sequence?

To me that is like saying any given thread may never execute one line of
code because the OS never schedules that thread to run!

*** Wait a minute I didn' say that your threads don't get scheduled, I said
this isn't guaranteed under the CLR, and you should never expect they are
scheduled in a FIFO order (or LIFO or any order at all). That's why it's
called "unfair thread synchronization ", and when your application absolutely
requires a fair thread synchronization (in a certain order) you shouldn't
use the .NET framework at all.

Why is that?
- When the CLR decides to kick a GC run, it determines which threads are
executing managed code and which are executing unmanaged code. When done the
CLR suspends the managed threads, unmanaged threads are treated specially
and can continue to run as long as they don't try to return to managed code.
Whenever the OS suspends a thread, it stops the thread waiting for a
synchronization object, later when the thread resumes, all suspended threads
start a race to obtain ownership of the synchronization object that it was
waiting on before the suspend. The result is that the threads (waiting for a
certain synchronization object) loose their order in the wait queue, and
loosing their order can possibly mean they don't get serviced for a long
period or worse they don't get scheduled at all.

- Other .NET API's that re-queue the wait order are WaitAll, WaitAny and
WaitOne.

Willly.

[Jon Skeet [C# MVP]]

Willy Denoyette [MVP] <wi************ *@pandora.be> wrote:

And what if the CurrentThread never equals the myArrayList[0] thread?
*One* of the ones which is unblocked by a call to PulseAll (sorry about
using the Java terminology before!) will be. Then everything moves down
the list (a queue would be better than an ArrayList here) and next time
the next thread gets a go.
This what I meant in my previous reply, don't count on it, the CLR doesn't
guarantee "fairness", so it's possible the thread your waiting for never get
serviced.
AFAIK there is no solution to this in managed world.

There is, and it can be encapsulated, I'm sure. It's probably not a bad
thing to write a utility class for - I'll give it a go when I get some
time.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[vooose]

Jon, you said:

<quote>
Yes - it's nastily inefficient, as you could have lots of threads which
end up taking most of the time calling Sleep. Instead, use a monitor
and Wait on it, then call NotifyAll on the monitor when you come out of
the appropriate block.
</quote>

Regarding the use of

while(myArrayLi st[0] != Thread.CurrentT hread)
Thread.Sleep(10 );

Lets say the average thread has to wait 50ms, so makes the call 5 times.
I'm not sure of the overhead of that versus the overhead of something
like

Monitor.Enter( )

I could see three things going on.

a) the waiting thread goes to sleep and is somehow woken up by the
locking thread calling Monitor.Exit( )

b) the waiting thread constantly checks to see if it can Enter( ).

c) somewhere in between, where it sleeps for a short period then checks
- something like what I coded above.
Obviously the best way would be a) but I'm not even sure it works like
this in the first place.

If indeed it *does* work this way, then I suppose instead of doing

while(myArrayLi st[0] != Thread.CurrentT hread)
Thread.Sleep(10 );

you could add it to a FIFO and somehow get it to sleep indefinitly (how
so?). Then when the CS thread exits it wakes the thread at the front of
the queue

--
Wal
http://www.vooose.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!