Semaphore signalling vs mutex

0
votes

I was looking over some topics that describes the difference between mutex and binary semaphore. In many topics it is stated that semaphore act as a signalling mechanism i.e if a thread has locked a semaphore then another thread can unlock(release) the semaphore(acting as signal). But in case of mutex only the thread that locks the mutex can unlock it .It can't be unlocked by any other thread and if other thread tries to unlock it this will return error.

I have tried writing a code that uses mutex for synchronization. In the code I am locking the mutex in one thread and successfully unlocking the mutex in other thread. Can someone please explain how this can happen.According to the answers everywhere the other thread should not be able to unlock mutex.

Any suggestions are most welcome.

3
linuxsynchronizationpthreadsmutexsemaphore
You seem to have false understanding of mutex semantics; your code is plain wrong if you are unlocking mutex before you lock it in the same thread. – FooF
Thanks FooF for correcting me.Actually I am not unlocking a mutex before locking it in same thread.But in one thread I am locking it and in other thread I am unlocking it. – amit12
The semantics for mutex is that you lock it, then do your thing with the resource the mutex is protecting, and then unlock the mutex. (Always keeping the mutex locked for minimal time - unless you use recursive mutexes which you should almost never use.) – FooF
If you want to signal between threads, you typically use a condtion variable associated with a mutex. There are plenty of examples online, or get Butenhof's excellent book on Pthreads. – Erik Alapää
for unlock() ... "The mutex must be locked by the current thread of execution, otherwise, the behavior is undefined." This means anything can happen, including it even might look like it is working. Also note, I have seen some thing assert-like reporting from inside mutex::unlock(), but not as often as I would expect. – 2785528

3 Answers

0
votes

Typical POSIX thread implementations do not perform any checks or validations that the thread unlocking a mutex is the same as the one that locked that (or likely even that the mutex was locked in the first place). This is not how mutexes are supposed to be used. The word "mutex" means mutual exclusion; the purpose of the concept is to provide a mechanism for multiple threads to safely access or modify a resource (e.g. data structure) without other threads interfering, and when done a modification have the resource in consistent state before unlocking the mutex.

It could be nice to catch such programming errors in run time (just like catching out of bounds writes to arrays), but by default providing such book-keeping and guards are too expensive in terms of performance; mutex locking and unlocking operations are supposed to give you minimal overhead for them to be usable. This is the reason you are succeeding in unlocking your mutexes from a wrong thread. In standard Linux pthread implementation you could use "error checking" mutexes, which would give you error when you try to unlock a mutex from a wrong thread, but again this check exists only to catch programming errors.

I am not able to advice you in compact form about what to use for and how to implement your signaling without better understanding of the nature of your signaling need.

0
votes

Any suggestions are most welcome.

I have had no problems using this Posix Process Semaphore encapsulation for std::thread as well as posix. 

//
#include <semaphore.h>  // posix semaphore

class PPLSem_t // Posix Process Semaphore, set to Local mode (unnamed, unshared)
{
public: //           not shared-between-process-v  v--initial-value-unlocked
   PPLSem_t()   { int stat = ::sem_init(&m_sem, 0, 1);  assert(0 == stat); } // ctor
   ~PPLSem_t()  { int stat = ::sem_destroy(&m_sem);     assert(0 == stat); } // dtor

   int lock()   { return (::sem_wait(&m_sem)); }   // returns 0 when success, else -1
   int unlock() { return (::sem_post(&m_sem)); }   // returns 0 when success, else -1
private:
   ::sem_t m_sem;
};

There is no restriction of which thread might signal it.

0
votes

According to pthread_mutex_lock man page: If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to unlock the mutex if it was not locked by the calling thread results in undefined behavior. Attempting to unlock the mutex if it is not locked results in undefined behavior.

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <string.h>
#include <errno.h>
#include <syscall.h>

pthread_mutex_t mutex;

void *thread(void *ptr)
{
    int ret = pthread_mutex_unlock(&mutex);

    if (!ret)
    {
        printf("error unlocking: %s", strerror(errno));
    }

    printf("tid: %u - owner: %u\n", syscall(SYS_gettid), mutex.__data.__owner);

    return NULL;
}

int main()
{
    pthread_t thread1;
    pthread_mutexattr_t attr;
    pthread_mutexattr_init(&attr);
    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK);
    pthread_mutex_init(&mutex, &attr);
    pthread_mutexattr_destroy(&attr);

    pthread_mutex_lock(&mutex);

    printf("tid: %u - owner: %u\n", syscall(SYS_gettid), mutex.__data.__owner);

    pthread_create(&thread1, NULL, thread, NULL);

    pthread_join(thread1, NULL);

    return 0;
}

Output for me:

tid: 13987 - owner: 13987
tid: 13992 - owner: 13987

The sole difference between mutex and binary semaphore is the owner concept. Mutex has an owner, so you "must" lock and unlock it in the same thread, but you can post or wait semaphore in different threads.