using CONDITION_VARIABLE with mutex HANDLE

Question

I'm trying to port one of my linux projects to windows.

In the project I use pthread_cond_t which, for being able to wait on, needed a pthread_mutex_t.
They are both concealed in different classes and the locking/waiting of them both should support timedwait.
Now, in linux it's all documented and easy, however on windows I find no documentation nor any questions related to it.

I know there are CONDITION_VARIABLEs but they are working only with CRITICAL_SECTIONs which cannot be timedwaited according to windows documentation, and of course there are HANDLE mutex that the CONDITION_VARIABLEs don't work with.

I do not want to use any boost or ace built-in objects or anything, I'm looking for pure operating system functions.

Is there something that i'm missing out here?

Answer 1

in linux it's all documented and easy - because there're many more synchronization primitives in Windows, and also the naming is different.

I find no documentation - I'd start with this article but beware it only covers a few of them. This list covers like ~50% of the most popular primitives.

"CONDITION_VARIABLEs but they are working only with CRITICAL_SECTION" - also with Slim Reader/Writer (SRW) Locks.

If you want better answer, you should probably tell us what functionality you require from synchronization primitives in your project.

P.S. If you are creating anything high-performance and scalable, you should not block threads at all. Very often, the most effective multithreading strategy on Windows is never wait for any synchronization primitives, only wait for user/IO subsystem/network/other external sources. I do understand however, that such apps should be designed that way from the start, which is impossible to achieve if you are porting from non-Windows platform.

Update: for studying purposes, (i.e. if you do not care about performance or latency or electric energy) you can easily implement waiting on a critical section object. Please see the sample code (untested):

static const DWORD msSleepTime = 100; // default time to sleep waiting for the CS
bool WaitForCriticalSection( LPCRITICAL_SECTION lpCriticalSection, DWORD msTimeout )
{
    if( dwTimeout == INFINITE )
    {
        EnterCriticalSection( lpCriticalSection );
        return true;
    }

    while( true )
    {
        if( TryEnterCriticalSection( lpCriticalSection ) )
            return true;
        if( msTimeout <=0 )
            return false;
        DWORD msToSleepTime = std::min( msTimeout, msSleepTime );
        Sleep( msToSleepTime );
        msTimeout -= msToSleepTime;
    }
}

For any production quality system however, this approach is unacceptable, and different approaches should be used instead. There is a good reason why you cannot wait on a critical section or SRW lock: you should not. They both were designed for lightweight user-mode thread synchronization. Normally, you should not lock them for longer than a few milliseconds. If you need to, it means using critical sections is just a waste of CPU resources and electric energy, and you should instead use e.g. mutex primitive.