Sponsored Content
Top Forums Programming pthread_mutex_init v. sem_init v. sem_get Post 302076613 by Corona688 on Wednesday 14th of June 2006 01:22:51 PM
Old 06-14-2006
A mutex is a mutal-exclusion device specifically designed to let one and only one thread have access to a certain code path at a time. If another thread tries to lock the mutex when it's already locked, that thread will be suspended until the first thread unlocks it.

Mutexes keep track of which thread "owns" them. An unlocked mutex is owned by nobody, once a thread locks it, it belongs to that thread; when they unlock it, it belongs to nobody again. Only the thread that locked the mutex is allowed to unlock it, and if it's owner tries to lock it again without unlocking it, the second lock will fail. Don't depend on this owner-checking, because some types of 'fast' mutexes dispense with it for efficiency.

here is a good example of how this kind of mutual exclusion is used -- it uses a slightly different thread API but the concept is exactly the same.

A semaphore is different from a mutex. Semaphores can store a range of values from zero to the maximum integer size, and don't track owners at all.

How a semaphore works is, when you "wait" on a sem, it attempts to vecrement the integer value. It will not let the count become negative -- if the integer value is zero, it will instead suspend the calling thread. The thread will stay suspended until something else "posts" on the semaphore, incrementing it and thus freeing the first waiting thread to2decrement it.

So if you had five threads waiting on one semaphore, you could let them go one at a time by posting to the sem 5 times.

One last difference between mutexes and semaphores is, semaphores aren't just thread-safe, they're even signal-safe. If for some reason you have to use thread synchronization inside signal handlers, they have to be semaphores. Otherwise you'll cause deadlocks.

I can't find sem_get anywhere in my system's manual pages. I'm not familiar with it.

Last edited by Corona688; 06-14-2006 at 02:28 PM..
 

We Also Found This Discussion For You

1. Programming

Undefined: sem_init, sem_post, sem_wait

Hi friends, I am using semaphores in my program, but when I compile the program, it gives the following error $ gcc sem.c -o sem -lpthread Undefined first referenced symbol in file sem_init ... (1 Reply)
Discussion started by: gabam
1 Replies
SEM_WAIT(2)						      BSD System Calls Manual						       SEM_WAIT(2)

NAME
sem_trywait, sem_wait -- lock a semaphore SYNOPSIS
#include <semaphore.h> int sem_trywait(sem_t *sem); int sem_wait(sem_t *sem); DESCRIPTION
The semaphore referenced by sem is locked. When calling sem_wait(), if the semaphore's value is zero, the calling thread will block until the lock is acquired or until the call is interrupted by a signal. Alternatively, the sem_trywait() function will fail if the semaphore is already locked, rather than blocking on the semaphore. If successful (the lock was acquired), sem_wait() and sem_trywait() will return 0. Otherwise, -1 is returned and errno is set, and the state of the semaphore is unchanged. ERRORS
sem_wait() and sem_trywait() succeed unless: [EAGAIN] The semaphore is already locked. [EDEADLK] A deadlock was detected. [EINTR] The call was interrupted by a signal. [EINVAL] sem is not a valid semaphore descriptor. NOTES
Applications may encounter a priority inversion while using semaphores. When a thread is waiting on a semaphore which is about to be posted by a lower-priority thread and the lower-priority thread is preempted by another thread (of medium priority), a priority inversion has occured, and the higher-priority thread will be blocked for an unlimited time period. Programmers using the realtime functionality of the system should take care to avoid priority inversions. SEE ALSO
sem_open(2), sem_post(2), semctl(2), semget(2), semop(2) HISTORY
sem_wait() and sem_trywait() are specified in the POSIX Realtime Extension (1003.1b-1993/1003.1i-1995). Darwin June 8, 2000 Darwin
All times are GMT -4. The time now is 09:36 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy