[M3devel] Re: [M3commit] CVS Update: cm3
Tony Hosking
hosking at cs.purdue.edu
Sat Jan 6 21:50:43 CET 2007
On Jan 3, 2007, at 10:14 PM, j k wrote:
>> 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".
I'll need to look again at my thinking on this. As I recall there
was a chicken and egg problem where we wanted *not* to run some code
until certain parts of the M3 run-time system were ready. Given that
one cannot fork a Modula-3 thread until after a given point in
initialization of the run-time system, I figured that certain idioms
would be safe even if not in the general case.
>
> 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
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
Antony Hosking | Associate Professor
Dept of Computer Science | Office: +1 765 494-6001
Purdue University | Mobile: +1 765 427-5484
250 N. University Street | Email: hosking at cs.purdue.edu
West Lafayette, IN 47907-2066 | http://www.cs.purdue.edu/~hosking
_--_|\
/ \
\_.--._/ )
v /
More information about the M3devel
mailing list