> Isn't a field "properly aligned in memory" when switch {$A8} is set?
That's what the online help let me think.
Conclusion:
In addition to the code I published, one need to use {$A8} directive (Or the
equivalent project option, which is set to 8 by default) for all classes
having their event handler modified by a thread which is not the thread
triggering the event.
For completness, here is the code:
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;
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 1:42 PM
Subject: Re:
[twsocket]Interestingmultithreadingissue:raceconditionwhentriggering anevent
handler
> Francois Piette wrote:
> > This raise the following question : Is a field variable in a class
> > aligned in memory ? (OnMyEvent variable is just a field variable).
>
> Isn't a field "properly aligned in memory" when switch {$A8} is set?
>
> ---
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
> > --
> > [EMAIL PROTECTED]
> > http://www.overbyte.be
> >
> > ----- Original Message -----
> > From: "Arno Garrels" <[EMAIL PROTECTED]>
> > To: "ICS support mailing" <twsocket@elists.org>
> > Sent: Monday, August 07, 2006 11:27 AM
> > Subject: Re: [twsocket] Interesting
> > multithreadingissue:raceconditionwhentriggering an event handler
> >
> >
> >> 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
> --
> 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
