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.