[M3devel] purported condition variable problems on Win32?
Rodney M. Bates
rodney_bates at lcwb.coop
Mon Jul 25 18:34:24 CEST 2016
BTW, I see yet a third concurrency bug in ThreadWin32.m3; In AssignSlot,
the code to allocate the first slots array, starting at :465
(* make sure we have room to register this guy *)
IF slots = NIL THEN
LeaveCriticalSection(ADR(slotLock));
slots := NEW (REF ARRAY OF T, 20);
EnterCriticalSection(ADR(slotLock));
END;
has a race with itself, that needs to be handled the same way that the
immediately following code, which enlarges an already-existing slots
array, does.
(* make sure we have room to register this guy *)
IF slots = NIL THEN
LeaveCriticalSection(ADR(slotLock));
new_slots := NEW (REF ARRAY OF T, 20);
EnterCriticalSection(ADR(slotLock));
IF slots = NIL (* still. *) THEN (* We won any races. *)
slots := new_slots;
END;
END;
Otherwise, not only could a different thread have allocated slots after the NIL
check and before the assignment to it, it could have put something into its
slots, and even enlarged it.
Also, both the initial and the enlarging NEW for slots should have an explicit
NIL check for out of memory.
On 07/25/2016 12:50 AM, Jay K wrote:
> btw, I think you are right.
>
>
> In particular, regarding the "directed notify" pattern,
> and the fact that we can have a per-thread event.
>
>
> I think you don't see this excact implementation stategy...
> you see people creating an event per wait...is because
> we have the feature and defect that we require our
> own runtime to create our threads, and we don't interoperate
> well with threads created otherwise...and there is a fix for this though,
> at least on Windows (where we are discussing anyway) via
> m3core.dll's DllMain, which we don't implement but probably should.
>
>
> So, let's go ahead and put support in Thread.T. or Thread.Activation
> and solve this?
>
> - Jay
>
>
>
--
Rodney Bates
rodney.m.bates at acm.org
More information about the M3devel
mailing list