Re: [linux-audio-dev] sysv semaphores instead of pipes

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] sysv semaphores instead of pipes
From: Peter Hanappe (peter_AT_hanappe.com)
Date: Tue Jun 26 2001 - 10:43:33 EEST

Paul Davis wrote:

>>> the problem with semaphores is that Unix/POSIX semantics don't allow
>>> integration of a process sleeping on an file descriptor and a
>>> semaphore (one of the few areas where Windows definitely improves upon
>>> Unix). this would mean adding yet another thread that just sleeps on
>>> the semaphore used to drive the "process" callback. Not terrible, but
>>> not particularly great either. The code would be a little cleaner, but
>>> we'd have an extra thread for every client. Uhm.

Hi,

I just wanted to make sure I understood that. (I might learn something
here). First, I guess SysV uses semget(2), semctl(2) and semop(2) to
handle semaphores. Does that mean that the following code would not be
correct:

   struct sembuf g_lock_sembuf[1];
   struct sembuf g_unlock_sembuf[1];

   g_lock_sembuf[0].sem_num = 0;
   g_lock_sembuf[0].sem_op = -1;
   g_lock_sembuf[0].sem_flg = 0;
   g_unlock_sembuf[0].sem_num = 0;
   g_unlock_sembuf[0].sem_op = 1;
   g_unlock_sembuf[0].sem_flg = 0;

   ....

   semop(g_sem_id, g_lock_sembuf, 1); /* lock semaphore */
   len = read(fd, buf, len); /* might block */
   semop(g_sem_id, g_unlock_sembuf, 1); /* unlock semaphore */

What could go wrong?

Do the same restrictions apply with the pthread semaphores
(semaphores(3), semaphore.h) or the pthread mutexes?

Thanks for the help!

Peter

New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jun 26 2001 - 11:38:38 EEST