POSIX semaphore and mutex sample producer--Consumer issues
One, POSIX signal volume
The concept of semaphores see here (http://www.bianceng.cn/OS/Linux/201308/37243.htm). The System V Semaphore is also mentioned earlier, and now it says the POSIX semaphore.
System V semaphores can only be used for interprocess synchronization, and the POSIX semaphore allows synchronization between threads, in addition to synchronization between processes. The System V Semaphore can be n per PV operation, but the POSIX semaphore can only be 1 per PV. In addition, the POSIX semaphore also has a naming and anonymity score (man 7 Sem_overview):
1, named Signal quantity
The name is distinguished in/somename form, only one/, and the total length cannot exceed name_max-4 (generally 251).
Need to create or open with the Sem_open function, PV operations are sem_wait and sem_post, you can use the sem_close shutdown, delete with Sem_unlink.
2, Anonymous signal volume
stored in a shared memory, if the thread is shared, this area can be a global variable, and if it is a process share, it can be System V shared memory (shmget creation, Shmat mapping), or POSIX shared memory (Shm_open creation, mmap mapping).
The anonymous semaphore must be initialized with Sem_init, one of the parameters of the Sem_init function determines whether thread sharing or process sharing, or sem_post and sem_wait operations, before the shared memory is released, the anonymous semaphore should be used first sem_ Destroy destroyed.
The specific parameters for these functions can be man.
Two, mutual exclusion lock
For multithreaded programs, the problem of access violations is common, and the solution is to introduce mutex (Mutex,mutualexclusive lock), the thread that gets the lock can complete the read-modify-write operation, and then release the lock to another thread, A thread that does not acquire a lock can only wait without access to the shared data, so that the read-modify-write three-step operation consists of an atomic operation, either executed or not executed, is not executed to the intermediate interrupt, and does not do this in parallel with other processors.
The mutex is represented by a variable of type pthread_mutex_t, the Pthread_mutex_init function initializes the mutex, the parameter attr sets the properties of the mutex, and if attr is NULL, the default attribute, see structure:
struct pthread_mutexattr_t
{
enum Lock_type //Use Pthread_mutexattr_settype to change
{
Pthread_mutex _TIMED_NP [default]//When a line Cheng, the rest of the thread requesting the lock forms the waiting queue, and the lock is obtained by priority after the unlock.
pthread_mutex_adaptive_np //action of the simplest type of lock, unlocked after the cable to compete again.
pthread_mutex_recursive_np //allows the same thread to be successfully obtained multiple times for the same lock. Of course, also to unlock several times. The remaining threads compete again when they unlock.
pthread_mutex_errorcheck_np //If the same thread request the same lock, return EDEADLK, otherwise the same as PTHREAD_MUTEX_TIMED_NP action.
} type;
attr
A mutex initialized with the Pthread_mutex_init function can be destroyed with Pthread_mutex_destroy. If the MUTEX variable is statically allocated (global or static), it can also be initialized with a macro definition Pthread_mutex_initializer, which is equivalent to initializing with Pthread_mutex_init and attr parameters to null.
A thread can invoke Pthread_mutex_lock to obtain a mutex, and if another thread has already called Pthread_mutex_lock to obtain the mutex, the current thread needs to suspend the wait until another thread calls the Pthread_mutex_ Unlock releases the mutex, and the current thread is awakened in order to obtain the mutex and continue execution.
The specific function above can be a man.