Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When can a cond var be used to synchronize its own destruction/unmapping?

According to POSIX,

It shall be safe to destroy an initialized condition variable upon which no threads are currently blocked.

Further, the signal and broadcast operations are specified to unblock one/all threads blocked on the condition variable.

Thus, it seems to me the following forms of self-synchronized destruction should be valid, i.e. calling pthread_cond_destroy:

  1. Immediately after a successful signal, in either the waiting or the signaling thread, when exactly one thread is blocked on the cond var.
  2. Immediately after a successful broadcast, in either any waiting thread or the broadcasting thread.

Of course this assumes no further waiters will arrive and no further signals shall be performed afterwards, which the application is responsible for guaranteeing if using pthread_cond_destroy.

Am I correct that destruction is valid in these situations? And are there other self-synchronized destruction scenarios to be aware of with condition variables?

Finally, for process-shared cond vars where unmapping the shared mapping without destruction might make sense, is it reasonable to expect unmapping to be valid in the same contexts destruction would be valid, or must further synchronization be performed if multiple threads in the same process (address space) are using the same mapping and want to unmap it in one of the above contexts?

like image 732
R.. GitHub STOP HELPING ICE Avatar asked Sep 29 '11 14:09

R.. GitHub STOP HELPING ICE


1 Answers

No, I don't think that most of your assumptions are correct. Returning from pthread_cond_signal or pthread_cond_broadcast does not indicate that any of the threads are yet "unblocked" from the condition variable, i.e that the threads that are to be unblocked don't need access to that variable anymore. The standard only says "shall unblock" and not "on successful return from this call they will be unblocked". The later would be very restrictive for implementations, so there is probably a good reason that this is formulated as it is.

So I think from the scenarios you describe only one is valid, namely the case were the solely blocked thread or process destroys the condition after being woken up.

like image 143
Jens Gustedt Avatar answered Sep 18 '22 14:09

Jens Gustedt