[M3devel] Re: [M3commit] CVS Update: cm3

[j k]

>I didn't look at the history for how the recursion got there.

Tony has made a bunch of changes here over the past months/years as part of 
using pthreads on other platforms.
Revision 1.8 looks suspicious.
It has Init call GetActivation.
GetActivation calls EnterCriticalSection(idleMu) which Init hasn't yet 
initialized.

Where I said "infinite recursion", substitute "entering an uninitialized 
critical section".

That might still lead to infinite recursion, like the access violation might 
be caught and code rerun or something. Feel free to undo my change and run 
the result. :)

- Jay

>From: "j k" <jayk123 at hotmail.com>
>To: wagner at elegosoft.com, jkrell at birch.elego.de
>CC: m3devel at elegosoft.com
>Subject: RE: [M3devel] Re: [M3commit] CVS Update: cm3
>Date: Thu, 04 Jan 2007 01:57:26 +0000
>
>
>
>I didn't look at the history for how the recursion got there.
>I didn't put it in.
>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.
>
>For the critical sections I just did a local analysis within the file which
>proved adequate to me. You can see fairly readily what are local variables 
>and what are gobals.
>
>There is a global linked list and the critical sections are used
>to protect it. But you can set up a local before putting it on the list 
>without the critical section.
>
>The shorter time you are in a critical section, the better.
>
>The critical sections are still overused or underused, in the pthread code 
>too.
>
>Consider this pthread code:
>
>PROCEDURE GetActivation (): Activation =
>  (* If not the initial thread and not created by Fork, returns NIL *)
>  (* LL = 0 *)
>  BEGIN
>    IF initActivations THEN InitActivations() END;
>    RETURN LOOPHOLE(Upthread.getspecific(activations), Activation);
>  END GetActivation;
>
>
>PROCEDURE InitActivations () =
>  VAR me := NEW(Activation);
>  BEGIN
>    WITH r = Upthread.key_create(activations, NIL) DO <*ASSERT r=0*> END;
>    WITH r = Upthread.setspecific(activations, me) DO <*ASSERT r=0*> END;
>    WITH r = Upthread.mutex_lock(activeMu) DO <*ASSERT r=0*> END;
>      <* ASSERT allThreads = NIL *>
>      me.handle := Upthread.self();
>      me.next := me;
>      me.prev := me;
>      allThreads := me;
>      initActivations := FALSE;
>    WITH r = Upthread.mutex_unlock(activeMu) DO <*ASSERT r=0*> END;
>  END InitActivations;
>
>The critical section might need to be expanded to encompass the 
>"initActivations" variable.
>
>Possible a "double check" is ok:
> if initActivations
>    enter critical section
>      if initActivations
>
>In Win32 you can probably get by with a simple spin lock using 
>InterlockedIncrement.
>Does pthreads have that?
>In Vista a "once" would be appropriate. I believe pthreads has those too.
>Use of simple booleans to implement "onces" is often done incorrectly.
>
>The critical section does not need to cover the lines:
>   me.next = me;
>   me.prev = me;
>   me.handle = Upthread.self();
>
>If this all is in some "startup" code that provides its own serialization, 
>then more of this is unnecessary.
>For example on Windows this should be in m3core.dll's DllMain(process 
>startup). It probably already is. I'd have to check.
>
>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...)
>
>It'd be nice to not roll custom linked lists btw, and then for there to be 
>a generic ThreadSafeList or such.
>
> - Jay
>
>
>
>
>
>
>
>From:  "Olaf Wagner" <wagner at elegosoft.com>
>To:  jkrell at birch.elego.de
>CC:  m3devel at elegosoft.com
>Subject:  [M3devel] Re: [M3commit] CVS Update: cm3
>Date:  Wed, 3 Jan 2007 16:38:05 +0100 (CET)
> >
> >On Sat, December 30, 2006 3:18 am, Jay Krell wrote:
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 06/12/30 02:18:06
> > >
> > > Modified files:
> > > cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.m3
> > >
> > > Log message:
> > > important: fix infinite recursion in Win32 startup
> > > correct check for TlsAlloc failure (TLS_OUT_OF_INDEXES instead of < 0)
> > > reduce critical sections slightly (esp. to avoid calling out while in 
>a
> > > critical section, including to
>DuplicateHandle, CreateThread, VirtualQuery)
> >
> >I would like to understand this change better (especially the first 
>item),
> >or at least how/why and endless recursion got into the source (as older
> >versions have run, haven't they?).
> >
> >As for critical sections, you seem to have remove one completely and
> >reduced another. Are you sure that is correct? (I've only had a short
> >look at the diff, and haven't got a comprehensive understanding of the
> >CM3 WIN32 runtime currently.)
> >
> >Olaf
> >--
> >Olaf Wagner
> >elego Software Solutions GmbH, Berlin, Germany
> >_______________________________________________
> >M3devel mailing list
> >M3devel at elegosoft.com
> >https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
>  Fixing up the home? Live Search can help
>


>_______________________________________________
>M3devel mailing list
>M3devel at elegosoft.com
>https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

_________________________________________________________________
Type your favorite song.  Get a customized station.  Try MSN Radio powered 
by Pandora. http://radio.msn.com/?icid=T002MSN03A07001