[M3devel] win32 threads/alert/race

Jay K jay.krell at cornell.edu
Mon Oct 5 16:27:14 CEST 2009


Tony can you clarify/confirm where you think the race is?

 

 

Is it here:

 

 

PROCEDURE InnerWait(m: Mutex; c: Condition; self: T) =
    (* LL = giant+m on entry; LL = m on exit *)
  BEGIN
    <* ASSERT( (self.waitingOn=NIL) AND (self.nextWaiter=NIL) ) *>

    self.waitingOn := c;
    self.nextWaiter := c.waiters;
    c.waiters := self;

    m.release();
    LeaveCriticalSection_giant();

 

     ** here ** ?


    IF perfOn THEN PerfChanged(State.waiting) END;
    IF WaitForSingleObject(self.waitSema, INFINITE) # 0 THEN
      Choke(ThisLine());
    END;
    m.acquire();
  END InnerWait;


Btw..just in case.. alerted and alertable could be "interlocked", even share bits in the same long.

If that helps.

 

Another thing to consider is that Win32 reserves the lower two bits of handles for users.

So you can imagine something even like where waitSema is in two places.

One place where it isn't used, always there.

Another place where if it is non-null it is going to be waited on.

You could merge setting of that copy of waitSema with the two bits alerted and alertable.

And set all three in one fell interlocked swoop.

Does that help?

 

 

I'm just mentioning random tricks, without understanding where the race is.

 

 

I'm just hoping you don't need a lock free manipulation of the waiters list.

That I have no good ideas on.

There is the slist stuff but I'm not keen on it, and I don't think it buys anything.

 

 

  - Jay






 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091005/555e567a/attachment-0001.html>


More information about the M3devel mailing list