Skip to content
Advertisement

Tag: semaphore

Strange POSIX semaphore behavior (stuck on sem_wait on Linux)

I’m trying to solve a school problem envolving POSIX semaphores. I’ve run into an issue that I’ve narrowed down to this simplified code: When compiling (using gcc -Wall -pthread sems.c -o sems) and running this program in Linux, I get the following output (the program doesn’t finish execution): Because I call sem_post(&sem) in the child process, I would expect the

C system v Semaphore not locking critical region

I have a code that reads an integer from shared memory and then incerements the number in child processes. I’m using semaphore to lock this critical region so that the integer gets only increased if no other process is not increasing it. So I get a stable integer value. I have used SYSTEM V Semaphore for that, however I’m not

Multithreading with Semaphor, Mutex and PThread

Me and a friend are currently working on basic multithreading examples for university in c. We’re supposed to solve the producer/consumer problem with a multithreaded buffer. We’ve got a working version using mutex and conditional variables, but trying to solve this using semaphores and mutex were having three major problems. Problem 1: If we start the consumer first he sometimes

How to find which process owns the named posix semaphore lock? [closed]

Closed. This question needs debugging details. It is not currently accepting answers. Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question. Closed 4 years ago. Improve this question I used named semaphore to synchronize multiple processes in my system. One of

what is “synchronising point” in multi threading?

I need to decide on how many counting semaphores needs to be used for one of the multi threaded application. I came to know, if we know synchronising points then we can decide the number of semaphores to be used. What are synchronising points? Answer A synchronization point is a place in the flow of execution where a thread must

Handling of blocked named semaphores after a system reboot

Within a Linux Box I’m using named semaphores to control access to system resources used by different processes. If the system accidentally crashes, it can happen, that a semaphore has been acquired but not given back yet. Given that situation, I noticed, that even after a reboot the semaphore remains still in a locked state. To overcome such situation, would

Semaphores and Mutex behaviour doubts

Do semaphores and mutexes synchronize both threads and processes, or only threads, or only processes? Edit: my mistake it’s C, not shell. Since I programmed through the shell I mistook it. And one more thing: are communication and synchronization the same? Answer SysV IPC semaphores synchronize between processes. With POSIX semaphores, you can choose via the pshared argument to sem_init(3)

Advertisement