Signalled and non-signalled state of event

Easy way to think of it: "signalled" = "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).

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

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

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.