Did you actualy *not* answer my question?
I can't find any answer in this post.
Are you willing to say out loud that *no* implementation would be able
to implement my locked_wait_all with zero atomic operations?
Are you saying so partialy? In what exact way?
I didn't make any assumptions about CV. I'm asking if it is possible
to *infer* (not assume) that some implementations could implement
locked_wait_all to be faster than locked_wait with no other costs.
That would require the clear description of how such implementation
works and how it would implement that (pointing out any real common
implementation that actualy does or doesn't could be helpful).
If you mind pointing out what assumption exactly I'd be happy, and I
will refrase (again) the exact same question without these assumptions
(generalize the question).
"likely are" means that also maybe not, in which case the answer to my
question should actually be: "yes, there exists a real/hypothetic
implementation that can do that...".
Do you mean you know how the common/most-used implementations work and
can tell for sure they don't fit my proposition?
Do you mean that they are "likely" not? By what measure "likely"?
I know that. It doesn't answer my question. I think my question could
come only after understanding that clearly.
My point is that this mutex could be used *also* for making sure that
the CV object access is synchronized, and not *only* for the unlock-
and-block mechanism. My point is that using the same locking on a
mutex for more things (instead using any other atomics and locks) can
[ See http://www.yqcomputer.com/
[ comp.lang.c++.moderated. First time posters: Do this! ]