Thread: SetEvent() and ResetEvent()?

  1. #16
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    >>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.

  2. #17
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Sebastiani View Post
    also, you might have better figuring out luck finding out the reasoning behind that snippet of code by simply going to the source - wherever CreateEvent and WaitForXXX are called. my guess is that the relevent code between was removed while the synchronization code remained (as a placeholder or simply because it was overlooked). who knows though, really.
    With spagetti code like this, my bets are on "overlooked".

  3. #18
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by abachler View Post
    As cutey pie said, SetEvent() is a system call, the system releases all waiting threads before returning. This doesnt mean they all execute immediately though, they are just scheduled for execution.
    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...?

  4. #19
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by cpjust View Post
    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.

  5. #20
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    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]

  6. #21
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #22
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    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.

    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.
    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.
    Last edited by abachler; 03-25-2008 at 10:04 AM.

  8. #23
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #24
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Codeplug View Post
    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]
    OK, now I think we're getting somewhere. So, in the code I provided, ResetEvent() will never run while SetEvent() is still running, right?

  10. #25
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by cpjust View Post
    OK, now I think we're getting somewhere. So, in the code I provided, ResetEvent() will never run while SetEvent() is still running, right?
    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.

  11. #26
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by matsp View Post
    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
    Thanks! That's all I needed to know.
    Now I can continue on with the rest of this spagetti code...

  12. #27
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by cpjust View Post
    Thanks! That's all I needed to know.
    Now I can continue on with the rest of this spagetti code...
    Yes, that's what it's all about isn't it... ;-)

    The funny thing is when you study your own code, after some years, it appears very hacky and spaghetti-ish, but it didn't seem so when you wrote it... ;-)

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

  13. #28
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by matsp View Post
    Yes, that's what it's all about isn't it... ;-)

    The funny thing is when you study your own code, after some years, it appears very hacky and spaghetti-ish, but it didn't seem so when you wrote it... ;-)

    --
    Mats
    Yeah, I noticed that about some of my old code, but I'm proud to say this isn't my code.

  14. #29
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by Elysia View Post
    When WaitForSingleObject sees that the object is signaled, it returns.

    So they are unrelated.
    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.

  15. #30
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    IF you want to be nitpicky then yes. I was simply giving a dumbed down explanation to separate the two.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed