Is event autoreset operation atomic?

[Kürþat]

Hi all,

I have a named autoreset event (EventWaitHandl e) and two applications one
waits on the event and one sets the evet. Application A calls Set method and
free a thread in application B. What I want to know is when Set method
returns can I assume event is certainly reset?

Is this ordering always true :

1- Application A calls Set method (No doubt)
2- Application B gets out of lock (2 or 3 or uncertain)
3- Set method returns (2 or 3 or uncertain)
4- Event is certainly reset now (?)

Thanks in advance.

[Kursat]

Hello Vadym,
Does Set method return before or after thread B released?

Thanks.

"Vadym Stetsyak" <va*****@ukr.ne twrote in message
news:%2******** ********@TK2MSF TNGP06.phx.gbl. ..

Hello, Kürþat!

KIs this ordering always true :

K1- Application A calls Set method (No doubt)
K2- Application B gets out of lock (2 or 3 or uncertain)
K3- Set method returns (2 or 3 or uncertain)
K4- Event is certainly reset now (?)

Set method uses win32 SetEvent. In case of an auto-reset event docs say:
"The state of an auto-reset event object remains signaled until a single
waiting thread is released, at which time the system automatically sets
the state to nonsignaled. If no threads are waiting, the event object's
state remains signaled."

That is the order above will look like
1 - App A calls Set method
2 - App B thread is released & event is put to non-singnaled state
3 - Event is reset until next Set call

So, event becomes reset when waiting thread is released...

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com

[Vadym Stetsyak]

Hello, Kursat!

AFAIK Set can exit before or after thread release.

Why do you care if its atomic?

IMO Set changes event object's state atomically, so there is no need to worry
about Set method itself.

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com

[Kursat]

Hi Vadym,

I try to set up a synchronization logic like this :

Thread A :
evt.Set (); // Release Thread B.
evt.WaitOne (); // Wait Thread B to complete.
// Thread B complete its job, go on

Thread B :
evt.WaitOne (); // Wait Thread A
doSomething ();
evt.Set (); // Job is done, release Thread A.

Initially Thread B waits Thread A to signal event. When Thread A signals
event, Thread B does something and Thread A waits on same event. After
Thread B completes its job it signals event and releases Thread A. Thus
Thread A knows when Thread B completes. This logic runs correctly only if
the event is certainly reset just after Set returns.

This is like SignalAndWait but only one WaitHandle used.
"Vadym Stetsyak" <va*****@ukr.ne twrote in message
news:uY******** ******@TK2MSFTN GP02.phx.gbl...

Hello, Kursat!

AFAIK Set can exit before or after thread release.

Why do you care if its atomic?

IMO Set changes event object's state atomically, so there is no need to
worry
about Set method itself.

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com

[Vadym Stetsyak]

Hello, Kursat!

[skipped]

KInitially Thread B waits Thread A to signal event. When Thread A signals
Kevent, Thread B does something and Thread A waits on same event. After
KThread B completes its job it signals event and releases Thread A. Thus
KThread A knows when Thread B completes. This logic runs correctly only
Kif the event is certainly reset just after Set returns.

Logic you've set up is correct Do you observe other results?

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com

[Kursat]

Hello Vadym,
It seems correct but observations are not enough to decide because, you
know, threads have random behaviors. So I think I must be sure about it
before use.

Thank you for your help.
"Vadym Stetsyak" <va*****@ukr.ne twrote in message
news:uH******** ******@TK2MSFTN GP06.phx.gbl...

Hello, Kursat!

[skipped]

KInitially Thread B waits Thread A to signal event. When Thread A
signals
Kevent, Thread B does something and Thread A waits on same event. After
KThread B completes its job it signals event and releases Thread A. Thus
KThread A knows when Thread B completes. This logic runs correctly only
Kif the event is certainly reset just after Set returns.

Logic you've set up is correct Do you observe other results?

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com