5 ms·
What bothers me is that the OCaml code looks so harmless: static void st_masterlock_acquire(st_masterlock * m) { pthread_mutex_lock(&m->lock);
by sbf501 4y ago
What bothers me is that the OCaml code looks so harmless:
static void st_masterlock_acquire(st_masterlock * m)
{
pthread_mutex_lock(&m->lock);
while (m->busy) {
m->waiters ++;
custom_condvar_wait(&m->is_free, &m->lock);
m->waiters --;
}
m->busy = 1;
pthread_mutex_unlock(&m->lock);
}
How is this bug not more common with such a simple invocation?
- asveikau 4y agoProbably you can get away with that simple invocation "most of the time", but what matters is the higher level code that calls it triggers the bug where other access patterns would not. Also, I do wonder why they roll their own mutex using condition variables. Most people probably would use a mutex and thus wouldn't hit the condition variable at all. Condition variables are more niche than mutex.
- mbac32768 4y agoAccording to Xavier Leroy (OCaml language dev): > It is possible to use a plain POSIX mutex as master lock, but fairness is awful. https://discuss.ocaml.org/t/is-there-a-known-recent-linux-locking-bug-that-affects-the-ocaml-runtime/6542/11?u=mbacarella https://discuss.ocaml.org/t/is-there-a-known-recent-linux-lo...
- sbf501 4y agoThanks. I've learned more about pthread just from this HN post than I've learned anywhere else online in the past few years. Makes me worried about some of my earlier code now. O_o
- jwatte 4y agoThat kinda depends on what custom_condvar_wait() does, right?
- grogers 4y agoJust 6 days ago they merged a custom condvar implementation based on futex directly to workaround the glibc bug. Before that it was just pthread_cond_wait