thanks,
hys
--
Hillel Y. Sims
hsims AT factset.com
> I was thumbing through a C# book today. For thread synchronization, they
> seem to use "Monitors" with mutex/condvar-like semantics ("Pulse" /
> "PulseAll" -- ala pthread_cond_signal / pthread_cond_broadcast, not related
> to Win32 PulseEvent). Didn't get any idea about cancellation semantics (if
> any). Anyone have any experience/opinions - how does it compare vs. Win32
> threading or pthreads? (no "brain-deads" w/o explanation, please... ;-)
I've only played around with it a little bit. Its kind of wierd
because they mixed in monitors but they still left in some Win32-style
event classes and single & multiple waits. Theres a wait to register and
wait for different WaitHandle objects.
From the limited amount I've done with C#, it looks like they are using
a mixed interruption and cancelation model. The interruption part is
something like deferred cancelation in pthreads but its closer to what
you'd find Java or ZThreads.
The cancelation part works through an Abort method that lets you just
raise an exception in the calling thread, but it's not really clear if
thats asynchronous or not. I think it is, but does anyone know for sure?
Its interesting though, a thread throws and exception and you can catch it
and handle it, but it keeps getting rethrown (even if you don't rethrow it)
until the stack unwinds or until you call another method to tell the thread
to knock it off and go back to work.
Then in addition to all that you've got someway to ignore Abort requests
for certain blocks of code; which kind of looks like deferred cancelation
in pthreads.
So, *I think*, you get Java monitor and interruption semantics with
Win32 events and multiple wait semantics with POSIX asynch cancelation
semantics. (?) Maybe its just so everyone has something that seems familiar to
encourage people to use C#. Or maybe its just too early in the morning
for me right now and I'm seeing things :)
Like i said though, I haven't done that much with C# yet so I could be
wrong, this is just the impression I got. You probably just decide which
way you want to go and just stick using that part of the System.Threads
package (are they packages in C#?, or they call em' something else?)
That's wrong. MS-pulsing-monitors sort-of 'mimic' Java ones. POSIX monitors
[mutex + n*condvar; n >= 1] is somewhat different thing... precise semantics
[mostly lacking in MS-spec] w.r.t. better performance/throughput [and robust
programming -- capable to 'handle' races w.r.t. changing the predicate and
signalling/broadcasting -> {re-}entering monitor's critical region] aside.
> not related
> to Win32 PulseEvent). Didn't get any idea about cancellation semantics (if
> any). Anyone have any experience/opinions - how does it compare vs. Win32
> threading or pthreads? (no "brain-deads" w/o explanation, please... ;-)
Cancellation aside [that's simply way too 'advanced' thing w.r.t.
MS-Corp 'products'... to even talk about it not risking to trigger
the permanent ROFLWTIME status... ending up in the clinic], consider:
http://groups.google.com/groups?selm=3D05DE77.8714CC38%40web.de
(Subject: Re: [OT] Beginner: C++ or C#)
http://groups.google.com/groups?selm=3CFE1D7F.96EC0C0F%40web.de
("This led Brinch-Hansen to express a great disappointment...."
Heck, MS-folks can't even comprehend what >>NOT<< to steal from
SUN's brain-dead Java)
regards,
alexander.
P.S. >>BRAIN-DEAD<< 'example' from MS site:
---
Send comments on this topic.
© 2001 Microsoft Corporation. All rights reserved.
---
[C#]
using System;
using System.Threading;
using System.Collections;
namespace MonitorCS1
{
class MonitorSample
{
const int MAX_LOOP_TIME = 1000;
Queue m_smplQueue;
public MonitorSample()
{
m_smplQueue = new Queue();
}
public void FirstThread()
{
int counter = 0;
lock(m_smplQueue)
{
while(counter < MAX_LOOP_TIME)
{
//Wait, if the queue is busy.
Monitor.Wait(m_smplQueue);
//Push one element.
m_smplQueue.Enqueue(counter);
//Release the waiting thread.
Monitor.Pulse(m_smplQueue);
counter++;
}
}
}
public void SecondThread()
{
lock(m_smplQueue)
{
//Release the waiting thread.
Monitor.Pulse(m_smplQueue);
//Wait in the loop, while the queue is busy.
//Exit on the timeout when the first thread stopped.
while(Monitor.Wait(m_smplQueue,1000))
{
//Pop the first element.
int counter = (int)m_smplQueue.Dequeue();
//Print the first element.
Console.WriteLine(counter.ToString());
//Release waiting thread.
Monitor.Pulse(m_smplQueue);
}
}
}
//Return the number of the queue elements.
public int GetQueueCount()
{
return m_smplQueue.Count;
}
static void Main(string[] args)
{
//Create the MonitorSample object.
MonitorSample test = new MonitorSample();
//Create the first thread.
Thread tFirst = new Thread(new ThreadStart(test.FirstThread));
//Create the second thread.
Thread tSecond = new Thread(new ThreadStart(test.SecondThread));
//Start threads.
tFirst.Start();
tSecond.Start();
//wait to the end of the two threads
tFirst.Join();
tSecond.Join();
//Print the number of the queue elements.
Console.WriteLine("Queue Count = " + test.GetQueueCount().ToString());
}
}
}
--
You Could Have Won >>ONE MILLION<< At http://sources.redhat.com/pthreads-win32
#include <disclaim.er>
I have a question.
what do you mean 'brain-dead' ?
and why is wrong example from ms site?
who explains?
sedere at unitel.co.kr
I mean 'brain-dead' >>DEAD<<lock, to begin with. Well, I guess, what
MS-folks tried to 'demonstrate' with their brain-dead example can be
found here:
http://groups.google.com/groups?selm=3BB18850.6BF7CF24%40web.de
(see tennis.c example)
> and why is wrong example from ms site?
Don't know, really. You should ask MS-folks -- click on "Send comments
on this topic." here:
> who explains?
Try to imagine that the second thread would race ahead of the first
one. No one will unblock the first thread (MS-'pulsars' aka MS-pulsing-
'monitors' even preclude spurious wakeups!); the second thread will
timeout, but the main/initial thread will 'deadlock' on joining the
1st thread. Such coding 'logic' is known as deadlock/brain-dead stuff,
AFAICT/IMHO.
regards,
alexander.
P.S. David, my old tennis.c example has a bug [race] w.r.t.
the signaling and condvar lifetime; that's exactly the stuff
I was pointing you at ("Try again" bit) here:
http://groups.google.com/groups?selm=3D0B3567.391D5B6A%40web.de
Do you see the point now? ;-)