2 ms·

For what is worth, which threads are guaranteed to be unblocked is defined by the standard, at least under realtime scheduling. I'm sure the rust devs got thei

For what is worth, which threads are guaranteed to be unblocked is defined by the standard, at least under realtime scheduling. I'm sure the rust devs got their condvar implementation exactly right at the first try, including cancellation, RT support, support for robust mutexes, wait morphing, process shared cond vars, etc. For human programmers like the glibc ones, it took many decades, and there are very few that are confident enough to make large changes. As I understand, there was no posix correct cond var for windows for many years untill after vista MS decided to expose the right primitives.

tialaramex 4y ago
> For what is worth, which threads are guaranteed to be unblocked is defined by the standard, at least under realtime scheduling. Where do you see this guarantee ? > including cancellation, RT support, support for robust mutexes, wait morphing, process shared cond vars, etc I'm sure doing the 100 metres sprint backwards, hopping on one leg while balancing a bowl of soup on your head would be trickier than the way Usain Bolt did it, but so what ? What glibc tries to do is very complicated, yet when we see people using this feature they overwhelmingly don't require any of the complications, they just want a condition variable and that's all Rust's Condvar offers.
- gpderetta 4y ago
  > Where do you see this guarantee ? The posix spec is not the easiest to read, but pthread_cond_signal has wordings on the effect that the ordering of wakeups is unspecified except under realtime scheduling. In any case glibc was blasted in the posix bug tracker for not respecting the wake up order even on non-RT and asking for the spec to be amended. Instead glibc had to rewrite its implementation to conform with the spec (and that fix introduced this bug). > I'm sure doing the 100 metres sprint backwards, hopping on one leg while balancing a bowl of soup on your head would be trickier than the way Usain Bolt did it, but so what ? you said that the complexity in glibc is not due to POSIX. All the items I mentioned (except for wait morphing) are required by POSIX/SUS. So what is it then?

tialaramex 4y ago

> For what is worth, which threads are guaranteed to be unblocked is defined by the standard, at least under realtime scheduling. Where do you see this guarantee ? > including cancellation, RT support, support for robust mutexes, wait morphing, process shared cond vars, etc I'm sure doing the 100 metres sprint backwards, hopping on one leg while balancing a bowl of soup on your head would be trickier than the way Usain Bolt did it, but so what ? What glibc tries to do is very complicated, yet when we see people using this feature they overwhelmingly don't require any of the complications, they just want a condition variable and that's all Rust's Condvar offers.

gpderetta 4y ago
> Where do you see this guarantee ? The posix spec is not the easiest to read, but pthread_cond_signal has wordings on the effect that the ordering of wakeups is unspecified except under realtime scheduling. In any case glibc was blasted in the posix bug tracker for not respecting the wake up order even on non-RT and asking for the spec to be amended. Instead glibc had to rewrite its implementation to conform with the spec (and that fix introduced this bug). > I'm sure doing the 100 metres sprint backwards, hopping on one leg while balancing a bowl of soup on your head would be trickier than the way Usain Bolt did it, but so what ? you said that the complexity in glibc is not due to POSIX. All the items I mentioned (except for wait morphing) are required by POSIX/SUS. So what is it then?