D
Dmitriy Vyukov
C++1x provides a complete toolset for lock-based programming: mutex
for ensuring consistency and condition variable for blocking/
signaling.
However, as for lock-free (non-blocking) programming C++1x provides
only atomics for ensuring consistency. And what about thread blocking/
signaling? Condition variables are of no help here, because they
require the state to be protected by a mutex. Yes, some lock-free
algorithms do not require blocking (for example, hash map). But things
like producer-consumer queues, work-stealing deques, etc, do require
some primitives for thread blocking/signaling.
I would like to hear from some people close to the committee on this.
How it's intended I must handle this?
Yes, I can build a semaphore from mutex+condvar+counter. And then
build blocking/signaling logic on top of the semaphore. However IMHO
it's (1) a kind of suboptimal from performance point of view and (2)
everybody will have to build it's own semaphore.
For example, Java provides thread park/unpark primitives for that
purpose, which is a kind of semaphore associated with every thread
with sticky signals and a maximum value of 1. IMHO, it's not the way
to go for C++1x, because one will have to pass thread objects
everywhere.
Thank you.
for ensuring consistency and condition variable for blocking/
signaling.
However, as for lock-free (non-blocking) programming C++1x provides
only atomics for ensuring consistency. And what about thread blocking/
signaling? Condition variables are of no help here, because they
require the state to be protected by a mutex. Yes, some lock-free
algorithms do not require blocking (for example, hash map). But things
like producer-consumer queues, work-stealing deques, etc, do require
some primitives for thread blocking/signaling.
I would like to hear from some people close to the committee on this.
How it's intended I must handle this?
Yes, I can build a semaphore from mutex+condvar+counter. And then
build blocking/signaling logic on top of the semaphore. However IMHO
it's (1) a kind of suboptimal from performance point of view and (2)
everybody will have to build it's own semaphore.
For example, Java provides thread park/unpark primitives for that
purpose, which is a kind of semaphore associated with every thread
with sticky signals and a maximum value of 1. IMHO, it's not the way
to go for C++1x, because one will have to pass thread objects
everywhere.
Thank you.