[Mono-list] Threading

Chris J. Breisch cjbreisch@altavista.net
Mon, 13 May 2002 09:50:13 -0500

I'm not sure that loading down your machine to "near-death" levels would
help.  You still have the same number of instructions to execute in the
new thread and the same number of instructions to execute in the ending
thread.  In any kind of round-robin (with aging and priority)
task-switching, it seems to me that the behavior in this setup should be
relatively consistent.

So, if csc consistently works as Jonathan expects and mcs does not, it
implies one of four things to me.

1) csc executes fewer instructions than mcs to start a thread
2) csc executes more instructions than mcs to end a process
3) csc temporarily sets the priority of the new thread higher than the
priority of the thread that started it
4) csc does an implicit Join() as Dick stated

I don't see any other possibilities.


Chris J. Breisch, MCSD, MCDBA

-----Original Message-----
From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com] On
Behalf Of Ian McCullough
Sent: Monday, May 13, 2002 9:26 AM
To: Jonathan Stowe
Cc: mono-list@ximian.com
Subject: Re: [Mono-list] Threading

> OK. That does what I expected ... except that with csc it does it
> the Join() everytime ...

Yeah -- I tested that before I posted my reply, and I couldn't get it to
fail in the same way, however I do think that this behavior is still "by
design" in that even though csc starts the thread in time, that it is
guaranteed to do so.  I suspect that if you loaded down your windows
to "near-death" levels, that the thread spawning process might take
time for the main thread to exit before the new thread got to its
Console.WriteLine statement.  The bottom line and the issue at the heart
this is that once you start a thread, there are no guarantees whatsoever
about execution order or synchronization unless you specifically put
guarantees in there using synchronization devices.


Mono-list maillist  -  Mono-list@ximian.com