Linux/pthreads equivalents for Windows API functions

The equivalent to pthread_mutex_t in Windows is a CriticalSection (fast mutex, not nestable, one process only) or a Mutex (processes and threads, nestable).

With both you could control an arbitrary resource, so that only one thread has exclusive access and all others that try to access while the resource is exclusively locked have to wait til unlock:

#ifdef PTHREAD
#   include <pthread.h>
    /*
     *  thread and mutex types
     */
    typedef pthread_t            Thread;
    typedef pthread_mutex_t  ThreadMutex;
#elif defined (WIN32)
    typedef unsigned long             Thread;
    typedef CRITICAL_SECTION    ThreadMutex;
#endif


/* one time initialization of a 'fast' mutex (not reversible) */
void initMutex(void* pMutex)
{
#if defined (PTHREAD)
     pthread_mutex_init((pthread_mutex_t*)pMutex, pthread_mutexattr_default);
#elif defined (WIN32)
     InitializeCriticalSection((PCRITICAL_SECTION)pMutex);
#endif
}

/* enter critical section and block others threads or wait                              */
void enterMutex(void* pMutex)
{
#if defined (PTHREAD)
     pthread_mutex_lock((pthread_mutex_t*)pMutex);
#elif defined (WIN32)
     EnterCriticalSection((PCRITICAL_SECTION)pMutex);
#endif
}
     
/* leave critical section and release any other thread blocked                         */
void leaveMutex(void* pMutex)
{
#if defined (PTHREAD)
     pthread_mutex_unlock((pthread_mutex_t*)pMutex);
#elif defined (WIN32)
     LeaveCriticalSection((PCRITICAL_SECTION)pMutex);
#endif
}


You would use this like:


ThreadMutex mutex;   // create global mutex

int main()
{
        initMutex(&mutex);

       // start some threads ...

       while (true)
       {
              doSomething();
              if (needToWriteToLogFile())
              {
                    // either we get the resource (logfile) exclusively or we have to wait
                    enterMutex(&mutex);
                   
                    ofstream oflog("logfile.log", ios::append | ios::out);
                    writeLog(oflog, "Any message");
                    oflog.close();
         
                    leaveMutex(&mutex);
              }
       }
 }
   

// thread.cpp

void threadFunction(void* pParam)
{
       while (true)
       {
              doSomeThreadThings();
              if (needToWriteToLogFile())
              {
                    // either we get the resource (logfile) exclusively or we have to wait
                    enterMutex(&mutex);
                   
                    ofstream oflog("logfile.log", ios::append | ios::out);
                    writeLog(oflog, "Any message");
                    oflog.close();
         
                    leaveMutex(&mutex);
              }
       }
}


Regards, Alex

Thanks for the quick reply.  I quickly found the relationship between CRITICAL_SECTION's and pthread_mutex_t's on my own (in fact, my code is much simpler ;) .  It is pthread_cond_t's which are confusing to me.  I would like to see a similar example implementing the producer/consumer paradigm with a boundless queue, or perhaps an explanation about when the condition gets reset.  Here is some pseudo-code for what I would like to achieve:

Main thread:

Create auto-reset (read) event
Create manual-reset (write) event
Create one producer
Create serveral consumers

Producer thread:

if ( wants to add )
{
    reset manual (write) event (set to unsignalled)
    wait for auto-reset (read) event
    add item
    signal both events
}

Consumer thread:

if( wants to remove )
{
    wait for both events   // This is where I would use WaitForMultipleObjects() in Windows API
    remove item
    signal auto-reset (read) event
}

In Windows, this pattern creates sort of a "priority flag" for the producer thread - once the 'write' event is unsignalled, the producer thread is guaranteed to be the next to run, because consumer threads will wait until the 'write' event is signalled.

WaitForMultipleObjects() in Windows may be used to wait for an entire array of events to become signalled or threads to complete, or to wait for just one in the set, much the same way as the select() sockets function works.  I would like to use it both ways.  It has occurred to me that perhaps the select() function itself might be used, but I have not had a chance to test my theory yet.

Thanks,
Shawn

>> Portable code as well?

I apologize, I did not mean sound critical of your code.  In fact, it's really the same code, I just like to define macros up front instead of mixing #ifdefs into my functions, if possible (and it was).

>> Actually, it seems to me that events isn't optimal to meet the requirements.

I do understand the uses for events.  I agree that a mutex would probably be a better fit for my example.  Truly, the point of the discussion is that I do not completely understand how pthread_cond_t's work.  I would like to have a synchronization construct in my library which implements the wait() / notify() paradigm.  In Windows, I use an event handle.  The functions which operate on pthread_cond_t's seem like they could be used, but I just don't see how it actually works.  I suppose I'll just have to get used to it.

I've found an interesting article on implementing windows style event handles and WaitForMultipleObjects() using POSIX threads:

http://developers.sun.com/solaris/articles/waitfor_api.pdf

Thanks for your help so far, I'll leave the topic open for discussion for a few days.

Shawn