|
From: Steven Stewart-G. <sst...@my...> - 2014-05-13 00:32:30
|
The FAQ mentions that there are some problems with condition variables and I
seem to get false reports about destroying waited on condition variables from
Helgrind. I'm using really simple code like the following:
struct linted_array_queue
{
pthread_mutex_t mutex;
pthread_cond_t on_empty;
pthread_cond_t on_full;
size_t message_size;
bool occupied;
char message_buffer[];
};
static void unlock_routine(void* arg)
{
pthread_mutex_t* mutex = arg;
pthread_mutex_unlock(mutex);
}
void linted_array_queue_send(struct linted_array_queue* queue,
void const* message)
{
pthread_mutex_lock(&queue->mutex);
pthread_cleanup_push(unlock_routine, &queue->mutex);
while (queue->occupied) {
pthread_cond_wait(&queue->on_empty, &queue->mutex);
}
queue->occupied = true;
memcpy(queue->message_buffer, message, queue->message_size);
pthread_cond_signal(&queue->on_full);
pthread_cleanup_pop(true);
}
I think it is correct but maybe Helgrind can't deal with condition variables and
cancellation. Is there any metadata or markup I can use to please Helgrind?
|
|
From: Steven Stewart-G. <sst...@my...> - 2014-05-13 21:35:20
|
> I think I observed a strange behaviour on Linux which does not comply > with POSIX. > That is, POSIX mandates that a thread blocked on pthread_cond_wait() > and canceled > via pthread_cancel() gets unblocked, the corresponding mutex > re-acquired and _then_ > cancellation cleanup handlers called. > However on Linux this was not true - thread unblocked from > pthread_cond_wait() did > not re-acquire the associated mutex. Thank you, Ivo Raisr. That makes sense and seems to fix my problem. I think the relevant section of POSIX is: > A side-effect of acting on a cancellation request while a thread is > blocked on a condition variable is to re-acquire the mutex before > calling any of the cancellation cleanup handlers. I find it strange that GLibc does not implement this case properly. |