CODEWITHSUNDEEP
cmultithreadingwinapi
Santhosh Pai
Santhosh Pai

Reputation: 2625

Signalled and non-signalled state of event

This could be a non programming question to all,i did read about the thread synchronization objects such as event and how it is set as signalled or non-signalled state . However i couldn't understand these terms signalled and non-signalled .Each one has expressed in different ways and i'm bit confused.

  1. This link states that

    A signaled state indicates a resource is available for a process or thread to use it. A not-signaled state indicates the resource is in use.

  2. I got an power point presentation from an university site which states that

    An object that is in the signaled state will not cause a thread that is waiting on the object to block and object that is not in the signaled state will cause any thread that waits on that object to block until the object again becomes signaled.

  3. This third link states this

    An event is in signaled state means that it has the capacity to release the threads waiting for this event to be signaled. An event is in non signaled state means that it will not release any thread that is waiting for this particular event.

A simple explanation on this concept with an example would be really helpful.

Upvotes: 14

Views: 12657

Answers (5)

Amir Shaharabany
Amir Shaharabany

Reputation: 1

to complete. there is the event reset handling. if the event is signaled, any thread blocked in event.wait(), or call event.wait() after signaled will continue, until event is reset. another option is the auto reset, that trigger the event reset( move event state to not signaled) after at least 1 thread is consuming the signaled event. if there are several threads waiting, they all continues after the event signaled, if no thread is waiting the next up coming thread that call event.wait() continues and the event is reset

Upvotes: 0

noelicus
noelicus

Reputation: 15055

Easy way to think of it: "signalled" = "green light"

Green Light Signalled: If you're driving and you see a green light you don't stop (this is the thread looking at an event, finding it's signalled and carrying on without blocking).

Red Light Non-Signalled: If you see a red light you stop and wait for it to become green and then carry on (safe in the knowledge the other threads all are now non-signalled thus are waiting or will wait at their...red light!)

Upvotes: 23

princio
princio

Reputation: 107

I don't really agree with other answers. They miss the point:

  • if signaled property is true => the event happened before now.

  • if signaled property is false => the event did not happened until now.

Where "signal property is false" equals to "not-signal property is true".

And the three definition all refers to threads but they are not clear because signal definition doesn't come from multi-threading but from low level programming .

Signals comes from interrupts:
"if that signal becomes high(=interrupt) move the execution pointer to this function".
This is the meaning of signal, and it comes from interrupts not from threading. And so, not-signaled means, the signal didn't become high until now.

In threading this become: "A thread needs that an event is happened to continue. If it's happend before now, it can continue; otherwise it blocks itself and wait for it."

Upvotes: 0

rodrigo
rodrigo

Reputation: 98338

Ok, your 3 quotes are not incompatible. But let's go a bit down to the implementation:

Every waitable object has a boolean value attached to it, named the signalled state, that is used to wait for that object; if the object is signalled, then the wait functions will not wait for it; if the object is non-signalled, then the wait functions will wait for it.

Now, how does this apply to a particular type of object? That depends on the objects nature and specifically on the semantics associated to waiting for it. Actually, the signalled state is defined in terms of wait condition. the For example (see the docs for details):

  • A mutex is signalled when it is not owned.
  • An process/thread is signalled when it has finished.
  • A semaphore is signalled when its count is greater than 0.
  • A waitable timer is signalled when it has expired.

You might like better if a mutex were signalled when owned, but actually it is when not owned. That's necessary to make the wait functions do the right thing.

And what about the events? Well, they are somewhat simple objects, you can signal and de-signal them at will, so the signal state has no additional meaning:

  • signalled: Threads will not wait for it.
  • non-signalled: Threads will wait for it.

Events also have this SignalPulse and AutoReset things that are a bit peculiar (and IME practically impossible to use right).

Now, let's look at your quotes:

A signaled state indicates a resource is available for a process or thread to use it. A not-signaled state indicates the resource is in use.

Actually, that is an interpretation. Usually there is a resource you are trying to arbitrate, and usually you wait if-and-only-if that resource is in use, so it is making the equivalence between resource-in-use and wait-for-resource. But that's not a technical requiremente, just a usual use-case.

An object that is in the signaled state will not cause a thread that is waiting on the object to block and object that is not in the signaled state will cause any thread that waits on that object to block until the object again becomes signaled.

Correct and to the point!

An event is in signaled state means that it has the capacity to release the threads waiting for this event to be signaled. An event is in non signaled state means that it will not release any thread that is waiting for this particular event.

I find this wording a bit confusing... but it adds nothing over the previous one.

Upvotes: 25

junix
junix

Reputation: 3211

Well, in fact all these explainations are congruent.

The most simplified (and hence not 100% accurate) explaination of an event is to see an event as kind of a flag service provided by the operating system. A signaled Event can be seen as a set flag, an unsignalled event on the other hand can be seen as an unset flag.

For implementing a producer/consumer thread-system based on flags, you usually do something like the following (note for the sake of simplicity i neglect further synchronization mechanisms):

static volatile int  flag = 0;
static volatile char data = 'A';

// Some code to initialize the threads  

void producer()
{
    while (1)
    {
        Sleep(1000);
        data++;
        flag = 1;
    }
}

void consumer()
{
    while (1)
    {
        /* Busy wait for the occurence of more data */
        while (!flag)
        {
            // wait for next data
        }

        flag = 0;

        // process data
    }
}

Unluckily this would lead to a waste of processor cycles in the busy wait loop or unwanted deferral of execution due to a Sleep call introduced to lower the CPU consumption. Both is unwanted.

In order to avoid such problems with task synchronization, operating systems provide different flag like mechanisms (e.g. Events in Windows). With events, setting and resetting a flag is done by the OS calls SetEvent/ResetEvent. To check for a flag you can use WaitForSingleObject. This call has the power to put a task to sleep until the event is signalled which is optimal in terms of CPU consumption.

This turns the above example into something like this:

static volatile char data = 'A';
static HANDLE newDataEvent = INVALID_HANDLE_VALUE;

// Some code to initialize the threads and the newDataEvent handle  

void producer()
{
    while (1)
    {
        Sleep(1000);
        data++;
        SetEvent(newDataEvent);
    }
}

void consumer()
{
    while (1)
    {
        if (WaitForSingleObject(newDataEvent, INFINITE) == WAIT_OBJECT_0)
        {
            ResetEvent(newDataEvent);
            // process data
        }
    }
}

Upvotes: 8

Related Questions