3 ms·

You are correct that deadlocks can be caused by signals occurring before the wait starts, and thus some sort of mechanism to ensure this does not happen is need

You are correct that deadlocks can be caused by signals occurring before the wait starts, and thus some sort of mechanism to ensure this does not happen is needed, but I explained as much in the article. The point of this API is that the atomic lock-switch is not restricted to just locks; and further, in some situations, no lock-switch is needed at all. The former is simple enough, and directly equivalent to what FreeBSD's API allows you to do (and what Haiku's API provides as "convenience methods", as the article notes), and is "atomic" -- it just pushes the atomicity up a level and lets the programmer control it more directly: ConditionVariableEntry entry; gSomeConditionVariable->Add(&entry); mutex_unlock(&someLock); /* (I could unlock more locks here, if needed, I'm not limited to 1) */ entry.Wait(); mutex_lock(&someLock); The latter case is the more interesting and unique one, and the article references one place it is actually used in practice (team/process creation), though it doesn't give a pseudocode example, so let me try to give one here: ConditionVariableEntry entry; someLongRunningOperation.conditionVariable->Add(&entry); someLongRunningOperation.start(); /* (I can do whatever I want here, no need to Wait immediately) */ entry.Wait(); Since this "long-running operation" is not even started until after the local Entry has been Add'ed to the Variable, there's no possible way for this operation to complete and signal before we have started 'waiting' (because, even if the Wait() call is at the end, it's the Add() call that counts.)

tialaramex 3y ago
> Since this "long-running operation" is not even started until after the local Entry has been Add'ed to the Variable, there's no possible way for this operation to complete and signal before we have started 'waiting' What you've got there is a "Happens before" constraint. Your "no possible way" is assuming Sequential Consistency, but I assure you that your CPU does not in fact provide Sequentially Consistent ordering of individual CPU operations across multiple cores. You need some way to reliably Order the events. It's possible that the vaguely named "atomic" operations in Haiku provide you with adequate ordering, but who knows since they don't specify.
- waddlesplash 3y ago
  > Your "no possible way" is assuming Sequential Consistency, I am assuming events cannot finish before they are started, yes! I am pretty sure that even the (in)famous DEC Alpha could not possibly have time-traveling results. Once again: there is a distinction between the API itself, and the API's implementation. Once the "Add" function returns, the "Entry" is now waiting on the "Variable". How the "Add" function ensures that is entirely abstracted away from the consumers of the API. The implementation of "Add", at least, is synchronized using a very standard spinlock, just like similar operations are for mutexes, semaphores, etc. not just on Haiku, but on all the BSDs and Linux. We don't even need to think about CPU operations ordering for that, the spinlock takes care of it for us. I am pretty sure Linux (and every other operating system, ever) would be in all kinds of trouble if you could read stale values from memory protected by spinlocks, so I don't know why you are casting doubt on these things. > It's possible that the vaguely named "atomic" operations in Haiku provide you with adequate ordering Hey, you already wrote a comment elsewhere in this thread about this point, and I replied to your comment with a bunch of information proving definitively: they do, in fact, provide that ordering. But in the cases I described in the parent comment here, it does not matter, because here we are talking about API consumption, not implementation.
  - tialaramex 3y ago
    > I am assuming events cannot finish before they are started, yes! I am pretty sure that even the (in)famous DEC Alpha could not possibly have time-traveling results. You seem to think this is a joke, but it isn't. Obviously from the CPU's point of view there is no "time travel" but that's cold comfort for users. The Alpha doesn't promise that there's any coherent ordering at all unless you've imposed one, which the sequentially consistent atomics Haiku is apparently asking for do. To get Sequential Consistency you're paying a very high price on such weakly ordered architectures. On x86 (and x86-64) the relative price is smaller, because everybody is paying for Acquire-release basically all the time, but it's still substantial on larger modern systems. This price isn't unique to Haiku, but the choice to pay it (almost) everywhere is, at least in terms of operating systems people would be using today.
wbl 3y ago
Ah so the add starts the period during which notifications will be caught ahead of the wait call.

tialaramex 3y ago

> Since this "long-running operation" is not even started until after the local Entry has been Add'ed to the Variable, there's no possible way for this operation to complete and signal before we have started 'waiting' What you've got there is a "Happens before" constraint. Your "no possible way" is assuming Sequential Consistency, but I assure you that your CPU does not in fact provide Sequentially Consistent ordering of individual CPU operations across multiple cores. You need some way to reliably Order the events. It's possible that the vaguely named "atomic" operations in Haiku provide you with adequate ordering, but who knows since they don't specify.

waddlesplash 3y ago
> Your "no possible way" is assuming Sequential Consistency, I am assuming events cannot finish before they are started, yes! I am pretty sure that even the (in)famous DEC Alpha could not possibly have time-traveling results. Once again: there is a distinction between the API itself, and the API's implementation. Once the "Add" function returns, the "Entry" is now waiting on the "Variable". How the "Add" function ensures that is entirely abstracted away from the consumers of the API. The implementation of "Add", at least, is synchronized using a very standard spinlock, just like similar operations are for mutexes, semaphores, etc. not just on Haiku, but on all the BSDs and Linux. We don't even need to think about CPU operations ordering for that, the spinlock takes care of it for us. I am pretty sure Linux (and every other operating system, ever) would be in all kinds of trouble if you could read stale values from memory protected by spinlocks, so I don't know why you are casting doubt on these things. > It's possible that the vaguely named "atomic" operations in Haiku provide you with adequate ordering Hey, you already wrote a comment elsewhere in this thread about this point, and I replied to your comment with a bunch of information proving definitively: they do, in fact, provide that ordering. But in the cases I described in the parent comment here, it does not matter, because here we are talking about API consumption, not implementation.
- tialaramex 3y ago
  > I am assuming events cannot finish before they are started, yes! I am pretty sure that even the (in)famous DEC Alpha could not possibly have time-traveling results. You seem to think this is a joke, but it isn't. Obviously from the CPU's point of view there is no "time travel" but that's cold comfort for users. The Alpha doesn't promise that there's any coherent ordering at all unless you've imposed one, which the sequentially consistent atomics Haiku is apparently asking for do. To get Sequential Consistency you're paying a very high price on such weakly ordered architectures. On x86 (and x86-64) the relative price is smaller, because everybody is paying for Acquire-release basically all the time, but it's still substantial on larger modern systems. This price isn't unique to Haiku, but the choice to pay it (almost) everywhere is, at least in terms of operating systems people would be using today.

wbl 3y ago

Ah so the add starts the period during which notifications will be caught ahead of the wait call.