Programming

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:
Threads will read from the list, by: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.

Code:

void timer_handler(int signum)
{
    tick++;    
}

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.

What do you think?

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.

THREAD 1

Code:

IF counter.t1 > 30
     SEND MESSAGE
     counter.t1 = 0;

THREAD 2

Code:

IF message[3] == 0x25
     counter.t1 = 0;

SIGNAL HANDLER

Code:

counter.t1++;

MAIN PROGRAM

Code:

INIT_SIGNAL;
START THREAD1
START THREAD2
while(1)
{
   IF counter.t1 == 25
      START NEW THREAD
}

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.

Code:

int signal_handler(int sig)
{
        sem_post(&sem);
}


void main_or_thread_that_counts_stuff(void)
{
        int count=0;

        while(1)
        {
                sem_wait(&sem);
                count++;
                if(count == 25)
                {
                        do_something();
                        count=0;
                }
        }
}

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.

Code:

thread1() 
{
         sem_wait(semCounter)
         if(new_message_recieved)
               counter.t1 = 0;
         sem_post(semCounter);
}
 
void timer_handler(int signum) 
{     
       // counters are removed from signal_handler
       sem_post(semTick); 
}

int main()
{
      // Start timer
      // start main threads

      while(1)
      {
             
            sem_wait(semTick);
            // code bellow will be executed once in a second
            sem_wait(semCounter);
            counter.t1++;
            sem_post(semCounter);
       }
}

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.