Re: [opensuse-programming] pthread_mutex vs semaphore.h ?
Roger Oberholtzer wrote:
On Mon, Jun 4, 2018 at 8:45 AM, Per Jessen <per@computer.org <mailto:per@computer.org>> wrote:
I'm reviving some old code, dates back to 2010. In one place I see I have replaced use of pthread_mutexes with sem_wait() and sem_post() (posix semaphores). I just can't see why I did it. :-(
The semantics are slightly different, but can anyone suggest why one should use one over the other? (or vice versa).
They would act differently. The pthread_mutexes typically wait for access to a variable. They do not wait for the variable itself to change. The sem_wait(), well, waits for the semaphore to change. Is the semaphore value itself the one you are interested in? Or does it's change mean that some variable you are interested in has changed? IMHO, pthread_mutexes are safer because when you access the protected variable, it should not be in the process of changing.
Thanks for your input, Roger. Here is what I wrote - //pthread_mutex_lock( &mux ); while( EINTR==sem_wait( &mux ) ); do some queue manip. //pthread_mutex_unlock( &mux ); sem_post( &mux ); mux is either a pthread_mutex_t or a sem_t. The queue manipulation is key, the mux is uninteresting. The reason I am looking at this is that a thread got hung up (over the weekend) - in the core dump, a signal handler was called and tried to write to the queue whilst someone was reading from the queue. It's possible that is why I had to move to using semaphores - I wonder if pthread_mutex_lock is async-safe. /Per -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming+owner@opensuse.org
Per Jessen wrote:
The queue manipulation is key, the mux is uninteresting. The reason I am looking at this is that a thread got hung up (over the weekend) - in the core dump, a signal handler was called and tried to write to the queue whilst someone was reading from the queue. It's possible that is why I had to move to using semaphores - I wonder if pthread_mutex_lock is async-safe.
I think that has to be the reasoning - pthread_mutex_lock/-unlock are not safe to call from a signal handler, whereas sem_wait/-post are. I'll have to double check. /Per -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming+owner@opensuse.org
Per Jessen wrote:
Per Jessen wrote:
The queue manipulation is key, the mux is uninteresting. The reason I am looking at this is that a thread got hung up (over the weekend) - in the core dump, a signal handler was called and tried to write to the queue whilst someone was reading from the queue. It's possible that is why I had to move to using semaphores - I wonder if pthread_mutex_lock is async-safe.
I think that has to be the reasoning - pthread_mutex_lock/-unlock are not safe to call from a signal handler, whereas sem_wait/-post are. I'll have to double check.
ah, well. sem_wait() isn't safe to call either, only sem_post(). Should have been obvious, duh. -- Per Jessen, Zürich (21.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming+owner@opensuse.org
On Mon, Jun 4, 2018 at 11:05 AM, Per Jessen <per@computer.org> wrote:
ah, well. sem_wait() isn't safe to call either, only sem_post(). Should have been obvious, duh.
We used to use signals in our 'real-time' data collection programs. We did, at some point, add threads into the mix. I think the problem is if the signal handler itself has anything at all to do with thread/mutex control. If threads/mutexes and signals are separate, then there is no problem (IMO). Of course we have eliminated all signal stuff. It was really more appropriate on unicore processors. When processors started having multiple cores (threads of control), threads make more sense. And the code is easier to follow/maintain. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming+owner@opensuse.org
Roger Oberholtzer wrote:
On Mon, Jun 4, 2018 at 11:05 AM, Per Jessen <per@computer.org> wrote:
ah, well. sem_wait() isn't safe to call either, only sem_post(). Should have been obvious, duh.
We used to use signals in our 'real-time' data collection programs. We did, at some point, add threads into the mix. I think the problem is if the signal handler itself has anything at all to do with thread/mutex control. If threads/mutexes and signals are separate, then there is no problem (IMO).
Yes, I'm sure that is correct.
Of course we have eliminated all signal stuff. It was really more appropriate on unicore processors.
I'm using aio, the completion of an operation is signalled with SIGAIODONE. In the signal handler, I had a call to a monitoring function, put some data in a ring buffer. I wanted to lock the getting of a buffer slot with the sem_wait/sem_post. For the time being, I have disabled that monitoring call, but I'll likely replace the sem_wait/sem_post with a busy lock in assembler. -- Per Jessen, Zürich (21.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming+owner@opensuse.org
participants (2)
-
Per Jessen -
Roger Oberholtzer