Subj : Re: Boss Told Me You Can't Use Semaphore, But I Have To Do Something like It!
To   : comp.programming.threads
From : David Schwartz
Date : Wed Jul 13 2005 02:35 pm


"Chris Friesen" <cfriesen@nortel.com> wrote in message 
news:11dau179dhntb0d@corp.supernews.com...

> David Schwartz wrote:

>> Semaphores were originally designed to be process-shared and do this in a 
>> natural way. Mutexes were originally designed to be process-local, and 
>> have process-shared support hacked on. For example, to create a 
>> semaphore, you just call the semaphore create function. To create a 
>> process-shared mutex, you have to allocate shared memory and then put the 
>> mutex in it.
>
> With semas, you have something like:
>
> semget() -- creation
> semctl() -- initialization
> semop() -- lock
> semop() -- unlock
>
> With process-shared mutexes you have something like:
>
> mmap() -- creation
> pthread_mutex_init() -- initialization
> pthread_mutex_lock() -- lock
> pthread_mutex_unlock() -- unlock
> pthread_mutex_destroy() -- cleanup
>
> There is a 1-to-1 mapping except for the cleanup in the mutex case. 
> There's nothing that says a mutex is for threads only, it's just a 
> structure in memory.  Whoever has access to that memory can use the mutex.

    The difference is that with a semaphore, creation makes whatever is 
needed to have a synchronization method. With mutexes, initialization may 
have to do that because it's not known what you're doing at creation time. 
For example, if something more than shared memory is needed to implement a 
process-shared mutex, the initialization will have to create it.

> Also, I actually like the pthreads API much better than the sysV one.

    Yes, if it's supported and if process-shared mutexes are available. 
Process-shared mutexes are still kludgy.

    DS

.