Use optimistic behavior in Barrier

[codemercenary]

This eliminates one lock acquisition during Barrier and implements a double-check pattern, which makes the Barrier routine significantly faster in cases where the queue is empty.

[wmisha]

Makes sense to me.

Shouldn't the if (onAborted) and both of the if (!m_count) checks be added to the non-timed Barrier() as well?

[codemercenary]

Actually that's a good point. The difference in behavior is going to have to be fixed another way.

In fact, if the count is zero, I still want to block for a single element from the queue to be dispatched. The reason is that the Barrier method is sometimes used to wait for a thread to finish starting, which means that I can't actually optimistically return just on the basis of the value of m_count, unless the timeout is also zero.

[wmisha]

Doesn't it still save computation if you keep the check on line 297?

And with this new logic, if timeout is zero but count is not, then shouldn't it still fail?

[codemercenary]

Ah crap, yes that was the intention, I wrote it wrong.

[codemercenary]

Also I can't keep that check. For the function to behave properly, I need to always pend that lambda to the queue and wait for the main thread to dispatch it, otherwise the timed Barrier routine cannot be used to wait for threads to start.

[wmisha]

Does the caller of Barrier know it's waiting for the thread to start? I imagine that that use case could be handled by the untimed Barrier instead, since the behavior is effectively untimed.

Unless "timed" in this case means:

• If the thread has started, wait for at most this length of time
• Otherwise, wait arbitrarily long for the thread to start

[codemercenary]

This class is used as the base class for CoreThread, and CoreThread calls WaitForEvent to drive the dispatch queue.

In Autowiring, I try to use the following paradigm:

1. All wait operations return void. Error conditions are signified with exceptions.
2. All wait operations have a timed variant that returns bool that signifies whether a timeout happened.

This is meant to parallel std::condition_variable::wait and std::condition_variable::wait_for, which have the same design.

The untimed DispatchQueue::Barrier would block until the next call to DispatchQueue::DispatchEvent. So, I need to ensure the timed variant of Barrier exhibits identical behavior.

An general exception are cases where zero is specified for the timeout. In that case, we infer that the user does not actually want to wait for anything, and instead the call should be interpreted to be a check for the underlying condition rather than a desire to block for some condition to be true.

[wmisha]

Ok, that makes more sense. Thanks for the explanation.