>>Event is opened by its name - so it is originally created in some other part of the code...
Oops; been out of the game too long... but hot damn, you guys are fast
>>Event is opened by its name - so it is originally created in some other part of the code...
Oops; been out of the game too long... but hot damn, you guys are fast
Just Google It. √
(\ /)
( . .)
c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.
So if that's the case, the call would have to block until all threads are released wouldn't it? Otherwise SetEvent() could release half of the threads when you suddenly call ResetEvent(). Then, what if ResetEvent finishes before SetEvent() does? Then there would be some threads that are signalled and some that aren't. Unless they're smart enough to know what each other is doing and cooperate...?
No, each thread has a decriptor entry that specifies if it is suspended or active (I'm oversimplifying for the sake of explanation). When you issue a SetEvent() command, the kernel marks any thread descriptors that are waiting on the event as active. When the kernel performs a task switch, it only switches to threads marked as active, it ignores suspended threads. In this way, SetEvent only blocks long enough for the kernel to mark the waiting threads as active, it doesnt wait for them to actually run. Even if it then immediately calls ResetEvent, the threads are already marked as active and will run until they call another wait function.
Last edited by abachler; 03-25-2008 at 09:20 AM.
SetEvent() doesn't block. Any threads currently waiting on the event are scheduled to run as abachler mentioned. Just think of SetEvent() as a function that runs in constant time. Calling ResetEvent() isn't going to change the fact that all those threads were scheduled to run. When those threads eventually get their time slice, they will return from whatever wait function they were blocked in.
>> Unless they're smart enough...
The OS is smart enough
gg
[edit]beaten[/edit]
I see them as just that - events. When signaled, they say "this even has now happened or is happening." It is no way related to threads.
WaitForSingleObject can be used to put a thread into sleep until some handle is signaled. This is, again, unrelated to SetEvent/ResetEvent.
You are wrong sugar, WaitForSingleObject() doesnt just take handles, it also takes any other signalable object including events and thread handles. Handles, events, mutex's, semaphores etc all share a common namespace, and are therefore related both intuitively and explicitly. SetEvent() explicitly releases all waiting threads before returning.
This implies that the function does indeed check for waiting threads. Either directly, or through the post suspension code in the waiting threads wait function.Any number of waiting threads, or threads that subsequently begin wait operations for the specified event object by calling one of the wait functions, can be released while the object's state is signaled.
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.
Last edited by abachler; 03-25-2008 at 10:04 AM.
Maybe I misworded it, but that's how it is. WaitForSingleObject and SetEvent are unrelated. WaitForSingleObject just waits for a handle to be signaled. SetEvent sets and ResetEvent resets and event. When WaitForSingleObject sees that the object is signaled, it returns.
So they are unrelated.
Correct - or at least, the actual part inside ResetEvent() can not be run at the same time as SetEvent() is being executed in it's act to set the event itself. The OS makes sure of this by using some suitable lock.
And pulsing the event is enough to trigger the WaitForXxxx() to return - it doesn't need to be active when the waiter actually gets to execute.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
The waiting thread is suspended while waiting, therefore it is not checking for the waitable object to become set. The SetEvent function is what clears the suspended status, therefor it is what wakes up the waiting thread. You may see it some other way, but thats the way it is.