Francois Piette wrote: >> This requires atomic reading/writing of a Pointer (no thread switch >> while read/write), I'm not sure whether this is true. > > I think so since pointer are 32 bits and are accessed by only one > memory cycle. If you look at the Windows API InterlockedXYZ function, > there is none to access a single 32 bit value. So I guess it is > guaranteed to have a 32 bit access done in one chunk.
In order to clear myself up finally I goggled a bit and found this: http://windowssdk.msdn.microsoft.com/en-us/library/ms684122.aspx "Simple reads and writes to properly-aligned 32-bit variables are atomic. In other words, when one thread is updating a 32-bit variable, you will not end up with only one portion of the variable updated; all 32 bits are updated in an atomic fashion. However, access is not guaranteed to be synchronized. If two threads are reading and writing from the same variable, you cannot determine if one thread will perform its read operation before the other performs its write operation. Simple reads and writes to properly aligned 64-bit variables are atomic on 64-bit Windows. Reads and writes to 64-bit values are not guaranteed to be atomic on 32-bit Windows. Reads and writes to variables of other sizes are not guaranteed to be atomic on any platform." But is this also true for Unix OS? Some articles I found say that atomicity is garanteed up to native int only. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > > Contribute to the SSL Effort. Visit > http://www.overbyte.be/eng/ssl.html -- > [EMAIL PROTECTED] > Author of ICS (Internet Component Suite, freeware) > Author of MidWare (Multi-tier framework, freeware) > http://www.overbyte.be > > > ----- Original Message ----- > From: "Arno Garrels" <[EMAIL PROTECTED]> > To: "ICS support mailing" <twsocket@elists.org> > Sent: Monday, August 07, 2006 9:35 AM > Subject: Re: [twsocket] Interesting multithreading issue: > raceconditionwhentriggering an event handler > > >> Arno Garrels wrote: >>> Francois PIETTE wrote: >>>> I've found an interesting multithreading issue which is related not >>>> The solution is to rewrite the procedure as follow: >>>> >>>> Line1: procedure TMyComponent.TriggerMyEvent(MyArg : Integer); >>>> Line2: var >>>> Line3: TMyEventProc EventProc; >>>> Line4: begin >>>> Line5: EventProc := OnMyEvent; >>>> Line6: if Assigned(EventProc) then >>>> Line7: EventProc(Self, MyArg); >>>> Line8: end; >>>> Saving the event pointer in line5 make sure that it is still valid >>>> in the case a thread switch between Line 6 and 7 occur and the >>>> OnMyEvent is set to nil by the other thread. >>>> >>>> Interesting, isn't it ? >>> >>> I think it's better/faster than having critical sections for all >>> triggers, do you plan to change all ICS triggers accordingly? >> >> This requires atomic reading/writing of a Pointer (no thread switch >> while read/write), I'm not sure whether this is true. Byte variables >> are written/read in one go, there's no ploblem. >> >> --- >> Arno Garrels [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> >> >> -- >> To unsubscribe or change your settings for TWSocket mailing list >> please goto http://www.elists.org/mailman/listinfo/twsocket >> Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
