<html><div style='background-color:'><DIV class=RTE>
<P>I didn't look at the history for how the recursion got there.<BR>I didn't put it in.<BR>It was definitely there and as it was, ANY attempt to run ANY Modula-3 code would crash in startup due to infinite recursion, stack overflow.</P>
<P>For the critical sections I just did a local analysis within the file which<BR>proved adequate to me. You can see fairly readily what are local variables and what are gobals.</P>
<P>There is a global linked list and the critical sections are used<BR>to protect it. But you can set up a local before putting it on the list without the critical section.</P>
<P>The shorter time you are in a critical section, the better.</P>
<P>The critical sections are still overused or underused, in the pthread code too.</P>
<P>Consider this pthread code:</P>
<P>PROCEDURE GetActivation (): Activation =<BR> (* If not the initial thread and not created by Fork, returns NIL *)<BR> (* LL = 0 *)<BR> BEGIN<BR> IF initActivations THEN InitActivations() END;<BR> RETURN LOOPHOLE(Upthread.getspecific(activations), Activation);<BR> END GetActivation;</P>
<P><BR>PROCEDURE InitActivations () =<BR> VAR me := NEW(Activation);<BR> BEGIN<BR> WITH r = Upthread.key_create(activations, NIL) DO <*ASSERT r=0*> END;<BR> WITH r = Upthread.setspecific(activations, me) DO <*ASSERT r=0*> END;<BR> WITH r = Upthread.mutex_lock(activeMu) DO <*ASSERT r=0*> END;<BR> <* ASSERT allThreads = NIL *><BR> me.handle := Upthread.self();<BR> me.next := me;<BR> me.prev := me;<BR> allThreads := me;<BR> initActivations := FALSE;<BR> WITH r = Upthread.mutex_unlock(activeMu) DO <*ASSERT r=0*> END;<BR> END InitActivations;</P>
<P>The critical section might need to be expanded to encompass the "initActivations" variable.</P>
<P>Possible a "double check" is ok:<BR> if initActivations<BR> enter critical section<BR> if initActivations</P>
<P>In Win32 you can probably get by with a simple spin lock using InterlockedIncrement.<BR>Does pthreads have that?<BR>In Vista a "once" would be appropriate. I believe pthreads has those too.<BR>Use of simple booleans to implement "onces" is often done incorrectly.</P>
<P>The critical section does not need to cover the lines:<BR> me.next = me;<BR> me.prev = me;<BR> me.handle = Upthread.self();</P>
<P>If this all is in some "startup" code that provides its own serialization, then more of this is unnecessary.<BR>For example on Windows this should be in m3core.dll's DllMain(process startup). It probably already is. I'd have to check.</P>
<P>Putting it in main is just about adequate, except that someone's .dll's DllMain(process startup) could create a thread that ends up in Modula-3 code. (There is the assertion about being created by Fork, which is unfortunate -- I should be able to use Modula-3 .dlls from non-Modula-3 code and I should be able to create threads with the system-native thread creater, CreateThread on Windows. Having to go through custom functions to create threads is not good. It requires more control of the system than you often have -- imagine for example providing a COM object implemented in Modula-3...)</P>
<P>It'd be nice to not roll custom linked lists btw, and then for there to be a generic ThreadSafeList or such.</P>
<P> - Jay<BR></P><FONT style="FONT-SIZE: 11px; FONT-FAMILY: tahoma,sans-serif"></FONT></DIV>
<DIV class=RTE><FONT style="FONT-SIZE: 11px; FONT-FAMILY: tahoma,sans-serif">
<P>
<HR color=#a0c6e5 SIZE=1>
</P></DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #a0c6e5 2px solid; MARGIN-RIGHT: 0px">
<DIV></DIV>From: <I>"Olaf Wagner" <wagner@elegosoft.com></I><BR>To: <I>jkrell@birch.elego.de</I><BR>CC: <I>m3devel@elegosoft.com</I><BR>Subject: <I>[M3devel] Re: [M3commit] CVS Update: cm3</I><BR>Date: <I>Wed, 3 Jan 2007 16:38:05 +0100 (CET)</I><BR>><BR>>On Sat, December 30, 2006 3:18 am, Jay Krell wrote:<BR>> > CVSROOT: /usr/cvs<BR>> > Changes by: jkrell@birch. 06/12/30 02:18:06<BR>> ><BR>> > Modified files:<BR>> > cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.m3<BR>> ><BR>> > Log message:<BR>> > important: fix infinite recursion in Win32 startup<BR>> > correct check for TlsAlloc failure (TLS_OUT_OF_INDEXES instead of < 0)<BR>> > reduce critical sections slightly (esp. to avoid calling out while in a<BR>> > critical section, including to
DuplicateHandle, CreateThread, VirtualQuery)<BR>><BR>>I would like to understand this change better (especially the first item),<BR>>or at least how/why and endless recursion got into the source (as older<BR>>versions have run, haven't they?).<BR>><BR>>As for critical sections, you seem to have remove one completely and<BR>>reduced another. Are you sure that is correct? (I've only had a short<BR>>look at the diff, and haven't got a comprehensive understanding of the<BR>>CM3 WIN32 runtime currently.)<BR>><BR>>Olaf<BR>>--<BR>>Olaf Wagner<BR>>elego Software Solutions GmbH, Berlin, Germany<BR>>_______________________________________________<BR>>M3devel mailing list<BR>>M3devel@elegosoft.com<BR>>https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<BR></FONT></BLOCKQUOTE></div><br clear=all><hr> <a href="http://g.msn.com/8HMAENUS/2731??PS=47575" target="_top">Fixing up the home? Live Search can help</a> </html>