You say I can only sem_post() inside a signal handler and only sem_wait() inside a threads?
You can only post inside a signal handler, but you can both post and wait inside threads.
Quote:
I have semaphores implemented on many places inside thread. What if one of my variable is changed more than once in a second ? - my signal handler goes on every second. Thread will have to wait after one variable change for a signal handler to release semaphore to continue processing.
It's possible to make a signal-safe queue to put your requests in so your threads can grab them at their leisure. It will need one semaphore, for the interrupt handler, and one mutex, for threads, and two integers: write postion and read position. Both start at zero.
When a signal happens:
Mask other interrupts.
Add the new event/data/whatever to the array.
Increment the write position. Wrap to zero if beyond the array.
sem_post.
Unmask other interrupts.
Threads will read from the list, by:
Lock the mutex
Save a copy of the read index
Increment the read index, wrap to zero if beyond the array
Unlock the mutex
sem_wait()
Read data from the saved index of the array
I originally put sem_wait first, but realized you could let the threads save positions in advance.
If signals happen faster than the threads can handle, the semaphore will keep track(it can count higher than one, it's not a mutex) and not block until they are all handled.
If signals happen way too fast for threads to handle, it's possible for the queue to overflow. Without a safe sem_getvalue this is hard to check for. If you're using gcc, you might try the gcc atomic operations extensions to get the read-index in a safe manner. (For that matter, they might let you dispense with the mutex entirely and grab-increment the read index atomically instead.)
Quote:
I'm also not sure if I need to check return value from sem_wait() and sem_post(). I have set SA_RESTART flag so if function call is interrupted by signal, function will be restarted after signal handler is finished.
If these functions weren't failing somewhere, why are you deadlocking? Always check the return value.
Last edited by Corona688; 09-03-2010 at 12:58 PM..
You can only post inside a signal handler, but you can both post and wait inside threads. It's possible to make a signal-safe queue to put your requests in so your threads can grab them at their leisure. It will need one semaphore, for the interrupt handler, and one mutex, for threads, and two integers: write postion and read position. Both start at zero.
When a signal happens:
Mask other interrupts.
Add the new event/data/whatever to the array.
Increment the write position. Wrap to zero if beyond the array.
sem_post.
Unmask other interrupts.
Threads will read from the list, by:
Lock the mutex
Save a copy of the read index
Increment the read index, wrap to zero if beyond the array
Unlock the mutex
sem_wait()
Read data from the saved index of the array
I originally put sem_wait first, but realized you could let the threads save positions in advance.
If signals happen faster than the threads can handle, the semaphore will keep track(it can count higher than one, it's not a mutex) and not block until they are all handled.
If signals happen way too fast for threads to handle, it's possible for the queue to overflow. Without a safe sem_getvalue this is hard to check for. If you're using gcc, you might try the gcc atomic operations extensions to get the read-index in a safe manner. (For that matter, they might let you dispense with the mutex entirely and grab-increment the read index atomically instead.)
If these functions weren't failing somewhere, why are you deadlocking? Always check the return value.
Thank you for your reply. I think I have found quicker and safer solution for problem.
I've removed all my code from signal handler and added variable increment.
I have an infinite lopp inside main(). I added usleep and copy&paste code from signal handler. Code is executed only on tick value change. Timing is not an issue.
I'm using SA_RESTART flag so if sem_wait() or sem_post() are interrupted by signal, they will be restarted. Now I have semaphores inside infinite loop inside main program and in threads. I don't think I should experience similar problem again.
Thank you for your reply. I think I have found quicker and safer solution for problem.
I've removed all my code from signal handler and added variable increment.
This isn't threadsafe. Variables aren't atomic and/or threadsafe on their own, that's why we need things like mutexes and semaphores.
All your solution amounts to is exactly what I suggested anyway: doing sem_post in the interrupt handler(increment the semaphore), and sem_wait inside the thread(decrement the semaphore). Treat the semaphore like a thread-safe integer that blocks the thing trying to decrement it if it goes below zero. You don't have to post and wait in both, it's not a mutex.
Quote:
I'm using SA_RESTART flag so if sem_wait() or sem_post() are interrupted by signal, they will be restarted. Now I have semaphores inside infinite loop inside main program and in threads. I don't think I should experience similar problem again.
What do you think?
You didn't expect them to fail before, either. You can't account for everything. Always check the return value of an important system call, it's not optional!
Last edited by Corona688; 09-03-2010 at 02:12 PM..
This isn't threadsafe. Variables aren't atomic and/or threadsafe on their own, that's why we need things like mutexes and semaphores.
All your solution amounts to is exactly what I suggested anyway: doing sem_post in the interrupt handler(increment the semaphore), and sem_wait inside the thread(decrement the semaphore). Treat the semaphore like a thread-safe integer that blocks the thing trying to decrement it if it goes below zero. You don't have to post and wait in both, it's not a mutex. You didn't expect them to fail before, either. You can't account for everything. Always check the return value of an important system call, it's not optional!
It looks like I have a lot of reading to do. I can't afford my self another case of deadlocking. I'll try to write threadsafe application like you suggested. Below is pseudo code of simplified behevior I like to achive.
It looks like I have a lot of reading to do. I can't afford my self another case of deadlocking. I'll try to write threadsafe application like you suggested. Below is pseudo code of simplified behevior I like to achive.
THREAD 1
THREAD 2
SIGNAL HANDLER
MAIN PROGRAM
I have no idea what the message[3] is, but if you're just counting signals here, you can just post in the handler and wait somewhere else like I've repeatedly suggested.
I know I can do it like you suggested but I have more complicated case. I will try to explain my application more clearly.
I building communication gateway that connects two industrial networks (I have two network interfaces). I have two important threads. First thread is listening on Ethernet port 0 (eth0). This thread is basically a infinite loop that accepts incoming connections and messages send via GPRS protocol. When new message is received, it is processed by another thread. This new thread writes log files (for example) .
Second thread is listening on eth1. In most parts it is basically the same as first thread, but it can have just one client and another protocol is implemented.
Same as in first thread, when new message is received, it is processed by another thread. When message is received, response is send back right away
and my counter (they are counting from zero to timeout value) are reset.
If there is no new messages (timeout occurs) new thread is open (now from main program, before from signal handler) and message (required by protocol)
is send by another thread.
I have few variables that are shared between threads and main program. Counter is just one of them. Counter is different because it is incremented every second.
Before joining this forum I had sem_wait() before variable increment/decrement/reinitialization operation which was followed by sem_post(). I didn't put
semaphores if I was just testing logical expression. I've changed that.
I'm thinking of doing sem_post inside signal handler and sem_wait inside infitine while loop inside main(). This way code inside infinite loop will run once in
a second and tick variable will be threadsafe. All other shared variables will have sem_wait() -> operation -> sem_post(). Is this ok? I've attached below new pseudo code.
One more question about checking error code. If my sem_wait() is interruped by signal, it will return EINTR regardles of SA_RESTART flag. This way I could execute sem_wait() two times and sem_post just once.
Quote:
If a blocked call to one of the following interfaces is interrupted by a
signal handler, then the call will be automatically restarted after the signal
handler returns if the SA_RESTART flag was used; otherwise the call will fail
with the error EINTR:
* POSIX semaphore interfaces: sem_wait(3) and sem_timedwait(3) (since
Linux 2.6.22; beforehand, always failed with EINTR).
Hello Everybody,
I am building a server. this server contains some data. Clients may modify this data or read this data.
If a client is reading the data and at the same time another client is modifying the data then at this case the reading client may read some false data (some old mixed with... (1 Reply)
I am having problem with semaphores. I am trying to protect line where process prints so that every process with print in proper order.This is the code..
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <sys/types.h>
union... (3 Replies)
Hello,
I was doing an exercise of semaphores and shared memory, namely the barbers:
-B number of barbers
-S number of chairs
-C number of customers.
I have done already and I compiled the code, but when run I get an error segment. Can not be and it took several days.
If anyone sees the error... (2 Replies)
Hello, first of all I apologize if this thread is not in the correct section of this forum, but this one just seemed the most appropriate.
The question I have does not concern Unix specifically, it applies to virtually any OS, however it is in Unix where I learned about this problem.
So, the... (8 Replies)
been searching around on how to use an up and down function with semaphores but i can't find an example. i looked into using: "semop" but i have no idea how to use it. I have been able to declared the semaphores using semget and initializing them using semctl. (7 Replies)
Hi Friends,
If i execute this command it comes back with 300 lines:
ipcs|grep cerebrus >>> i would like to clear the semaphores but ipcrm can remove one id at a time. is there a quicker way of removing semaphores maybe using awk?
Regards, (1 Reply)
Hi there,
Could someone please confirm which POSIX semaphore routines should be used for a multiprocess (and not multithreaded) environment?
sys/sem.h definitely works. but the routines, semget, semctl, semop are pretty unwieldy. So, I am looking for an easier way out.
From the man pages... (2 Replies)
Hi all,
I am using HP 10.20 on A 9000/785. My question is:
If I am the only person logged in as root at the moment, how many "semaphore proccesses" should I have?? Is it only one, or it is relevant to other system proccesses?
Here is what I get listing the current semaphores
# ipcs -sp... (1 Reply)
Dear Reader,
I'm in a multiprocess environment working with shared mem and semaphores as mutex.. The problem is -- If one of the process hooked up with the semaphore and accessing the shared mem, terminates abruptly ( or got killed ), other process which are in want of the semaphore are... (1 Reply)