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?

SleepConditionVariableCS takes a timeout and is equivalent to pthread_cond_timedwait(). — Hans Passant
– Hans Passant, Commented Feb 10, 2014 at 12:31
I know, but then CONDITION_VARIABLE is in a class and CRITICAL_SECTION is in a class but CRITICAL_SECTION cannot be waited on and that's a must. — atlanteh
– atlanteh, Commented Feb 10, 2014 at 17:13

Soonts · Accepted Answer · 2014-02-10 18:15:19Z

2

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.

edited Feb 10, 2014 at 18:15

answered Feb 10, 2014 at 15:11

Soonts

22.3k11 gold badges68 silver badges147 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

atlanteh Over a year ago

It's a rather small project. The porting is mainly for windows studying purposes and i'm trying to leave the api as intact as possible. My main question is: Is there anyway to get some kind of CONDITION_VARIABLE class and MUTEX class that are both waitable and that the CONDITION_VARIABLE uses the MUTEX to lock itself?

atlanteh Over a year ago

Thx a lot for your help! I was trying to avoid busy waiting, but it seems there's no alternative for this case. :))

Soonts Over a year ago

Sleep API is not really busy waiting, it just reschedules threads. Having a thread that wakes up every 100 milliseconds to check some condition is only considered "busy waiting" in a mobile environment where electric energy is scarce. But, it obviously bring extra latency (at least 50 milliseconds average).

Collectives™ on Stack Overflow

using CONDITION_VARIABLE with mutex HANDLE

1 Answer 1

3 Comments

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

3 Comments

Your Answer

Sign up or log in

Post as a guest

Linked

Related