Re: [twsocket] Interesting multithreading issue: raceconditionwhentriggering an event handler

2006-08-07 Thread Fastream Technologies 
- Original Message - 
From: Wilfried Mestdagh [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Monday, August 07, 2006 10:40 AM
Subject: Re: [twsocket] Interesting multithreading issue: 
raceconditionwhentriggering an event handler


: Hello Arno,
:
:  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.
:
: As far as I know it is also the case with a 32 bit. So should be no
: problem.

I think it is related with what the machine word is. For Athlon 64, it is 
64 bits!

Regards,

SZ 

-- 
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

Re: [twsocket] Interesting multithreading issue: raceconditionwhentriggering an event handler

2006-08-07 Thread Francois Piette 
 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.

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