Topic: N3533 - C++ Concurrent Queues - Externally locked
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 26 Mar 2013 21:02:32 +0100
Raw View
This is a multi-part message in MIME format.
--------------040609040004080307050703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
N3533 adds some non-blocking specific operations for lock based
concurrent queues.
The design in N3533 can not return a reference on the function pop.
Olaf has suggested a push operation taking multiple elements. Another
case is to have a pop operation that pops several elements on just
transfer the whole contents of the queue on one shot.
Next follows an alternative design using an externally locked queue
which could be more appropriated in some contexts. N3535 C++ Stream
Mutex C++ [1] proposal follows this pattern also. For those that don't
know this idiom see the paper of Andrei Alexandrescu "Multithreading and
the C++ Type System". Boost.Thread contains some classes that helps to
implement this idiom
[2]. Boost.Thread provides also a externally locked stream [3] that is a
variant of N3535.
Using a externally locked concurrent queues the user could do the following.
Given the following declaration
std::externally_locked_queue<int> elkq; // contains its own
std::queue<int> and a std::mutex.
Push multiple elements on the queue elkq
{
auto lkq=elkq.hold(); // obtains a lock with a concurrent queue
interface
lkq.push(1); //uses any concurrent operation without blocking
(already done)
lkq.push(2);
}
Return an element by reference
int e = elkq.hold().pop();
Note that the internal mutex is unlock after the statement when the
temporary returned by hold() is destroyed.
Move the whole queue
std::queue<int> qr = std::move<std::queue<int>>(elkq.hold());
Managing with non-blocking operations implies the user will do the
operation in two steps
// writing one element without blocking on a specific thread W
{
auto lkq=elkq.try_hold(); // obtains a try-locker
if (lkq) {
if (lkq.get().try_push(1))) { lkq.unlock(); ... } // code
associated to result queue_op_result::success
else { lkq.unlock(); ... } // code
associated to result queue_op_result::full
} else { ... } // code associated to result queue_op_result::busy
}
I recognize that the code is a little bit *more complex* than the one
using the interface in N3533
queue_op_result res=cq.try_push(1);
if( (res== queue_op_result::success) ... // code associated to
result queue_op_result::success
else if (res== queue_op_result::full) ... // code associated to
result queue_op_result::full
else if (res== queue_op_result::busy: ... // code associated to
result queue_op_result::busy
and the worst been that it *needs to **unlock* :(
It has however some advantages:
* allows *multiple access* to the queue with a single lock as showed above
* could provide a concurrent queue interface that allows
*returning-reference*
* the name of the operation is simple as the operations do less.
Has this alternative design been considered?
Do you see other drawbacks?
It is worth making a proposal for a generic externally_locked helper
class as the one in Boost.Thread?
Best,
Vicente
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3535.html
[2]
http://www.boost.org/doc/libs/1_53_0/doc/html/thread/synchronization.html#thread.synchronization.tutorial.external_locking_____strict_lock__and__externally_locked__classes
[3]
https://svn.boost.org/svn/boost/trunk/boost/thread/externally_locked_stream.hpp
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--------------040609040004080307050703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DISO-8=
859-1">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Hi,<br>
<br>
N3533 adds some non-blocking specific operations for lock based
concurrent queues. <br>
The design in N3533 can not return a reference on the function pop.<br>
Olaf has suggested a push operation taking multiple elements.
Another case is to have a pop operation that pops several elements
on just transfer the whole contents of the queue on one shot. <br>
<br>
<br>
Next follows an alternative design using an externally locked queue
which could be more appropriated in some contexts. N3535 C++ Stream
Mutex C++ [1] proposal follows this pattern also. For those that
don't know this idiom see the paper of Andrei Alexandrescu
"Multithreading and the C++ Type System". Boost.Thread contains some
classes that helps to implement this idiom<br>
[2]. Boost.Thread provides also a externally locked stream [3] that
is a variant of N3535.<br>
<br>
Using a externally locked concurrent queues the user could do the
following.<br>
<br>
Given the following declaration<br>
<br>
std::externally_locked_queue<int> elkq; // contains its ow=
n
std::queue<int> and a std::mutex.<br>
<br>
Push multiple elements on the queue elkq <br>
<br>
{<br>
auto lkq=3Delkq.hold(); // obtains a lock with a concurren=
t queue
interface<br>
lkq.push(1); //uses any concurrent operation without blocking
(already done)<br>
lkq.push(2); <br>
}<br>
<br>
Return an element by reference<br>
<br>
int e =3D elkq.hold().pop();<br>
<br>
Note that the internal mutex is unlock after the statement when the
temporary returned by hold() is destroyed.<br>
<br>
Move the whole queue<br>
<br>
std::queue<int> qr =3D
std::move<std::queue<int>>(elkq.hold());<br>
<br>
Managing with non-blocking operations implies the user will do the
operation in two steps<br>
<br>
// writing one element without blocking on a specific thread W<br>
{<br>
auto lkq=3Delkq.try_hold(); // obtains a try-locker<br>
if (lkq) {<br>
if (lkq.get().try_push(1))) { lkq.unlock(); ..=
.. } // code
associated to result queue_op_result::success<br>
else { lkq.unlock(); ... } &nbs=
p; &=
nbsp; //
code associated to result queue_op_result::full<br>
} else { ... } &n=
bsp;  =
; =
// code associated to result queue_op_result::busy<br>
}<br>
<br>
I recognize that the code is a little bit <b>more complex</b> than
the one using the interface in N3533<br>
<br>
queue_op_result res=3Dcq.try_push(1);<br>
if( (res=3D=3D queue_op_result::success) ... // code asso=
ciated to
result queue_op_result::success <br>
else if (res=3D=3D queue_op_result::full) ... =
// code associated to
result queue_op_result::full  =
; <br>
else if (res=3D=3D queue_op_result::busy: ... // code asso=
ciated to
result queue_op_result::busy <br>
<br>
and the worst been that it <b>needs to </b><b>unlock</b> :( <br>
<br>
It has however some advantages:<br>
* allows <b>multiple access</b> to the queue with a single lock as
showed above<br>
* could provide a concurrent queue interface that allows <b>returning-r=
eference</b><br>
* the name of the operation is simple as the operations do less.<br>
<br>
Has this alternative design been considered? <br>
Do you see other drawbacks?<br>
It is worth making a proposal for a generic externally_locked helper
class as the one in Boost.Thread?<br>
<br>
Best,<br>
Vicente<br>
<br>
[1]
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2013/n3535.html">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2013/n3535.html</a> <br>
[2]
<a class=3D"moz-txt-link-freetext" href=3D"http://www.boost.org/doc/libs/1_=
53_0/doc/html/thread/synchronization.html#thread.synchronization.tutorial.e=
xternal_locking_____strict_lock__and__externally_locked__classes">http://ww=
w.boost.org/doc/libs/1_53_0/doc/html/thread/synchronization.html#thread.syn=
chronization.tutorial.external_locking_____strict_lock__and__externally_loc=
ked__classes</a><br>
[3]
<a class=3D"moz-txt-link-freetext" href=3D"https://svn.boost.org/svn/boost/=
trunk/boost/thread/externally_locked_stream.hpp">https://svn.boost.org/svn/=
boost/trunk/boost/thread/externally_locked_stream.hpp</a><br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------040609040004080307050703--
.
Author: Lawrence Crowl <crowl@googlers.com>
Date: Tue, 26 Mar 2013 14:51:46 -0700
Raw View
On 3/26/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> It has however some advantages:
> * allows *multiple access* to the queue with a single lock as showed above
> * could provide a concurrent queue interface that allows
> *returning-reference*
> * the name of the operation is simple as the operations do less.
Correct me if I am wrong, but wouldn't this goal be achieved by
adding lock operations to deque? (I suspect ABI issues would
inhibit that, but, for discussion, assume it is okay.)
Such an approach can be useful, but it does not admit lock-free
queues, and so I wouldn't want it to replace the existing proposal.
> Has this alternative design been considered?
> Do you see other drawbacks?
> It is worth making a proposal for a generic externally_locked helper
> class as the one in Boost.Thread?
We have lots of existing data structures that may need locking.
It seems reasonable to me to have a standard helper class that lets
folks do that in sharable ways.
--
Lawrence Crowl
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 26 Mar 2013 23:17:01 +0100
Raw View
Le 26/03/13 22:51, Lawrence Crowl a =E9crit :
> On 3/26/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
>> It has however some advantages:
>> * allows *multiple access* to the queue with a single lock as showed abo=
ve
>> * could provide a concurrent queue interface that allows
>> *returning-reference*
>> * the name of the operation is simple as the operations do less.
> Correct me if I am wrong, but wouldn't this goal be achieved by
> adding lock operations to deque? (I suspect ABI issues would
> inhibit that, but, for discussion, assume it is okay.)
Sorry, I don't understand. Are you talking of the last advantage?
>
> Such an approach can be useful, but it does not admit lock-free
> queues, and so I wouldn't want it to replace the existing proposal.
My suggestion pretends to just provide an alternative not a replacement.
Even if *artificial* the result of hold() for a lock-free queue could be=20
a no-op.
>
>> Has this alternative design been considered?
>> Do you see other drawbacks?
>> It is worth making a proposal for a generic externally_locked helper
>> class as the one in Boost.Thread?
> We have lots of existing data structures that may need locking.
> It seems reasonable to me to have a standard helper class that lets
> folks do that in sharable ways.
>
This helper class could be used to provide a thread safe interface to=20
any sequential data structure. The external lock can be used also for=20
waiting data structures as concurrent queues. Anyway, I recognize that=20
concurrent queue merits a special consideration.
Would someone champion a proposal including this helper class?
Best,
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Lawrence Crowl <crowl@googlers.com>
Date: Tue, 26 Mar 2013 17:38:03 -0700
Raw View
On 3/26/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> Le 26/03/13 22:51, Lawrence Crowl a =E9crit :
> > On 3/26/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> > > It has however some advantages:
> > > * allows *multiple access* to the queue with a single lock
> > > as showed above
> > > * could provide a concurrent queue interface that allows
> > > *returning-reference*
> > > * the name of the operation is simple as the operations do less.
> >
> > Correct me if I am wrong, but wouldn't this goal be achieved by
> > adding lock operations to deque? (I suspect ABI issues would
> > inhibit that, but, for discussion, assume it is okay.)
>
> Sorry, I don't understand. Are you talking of the last advantage?
I was asking if adding deque::lock() deque::unlock() would meet
the need, ignoring general wrappers. I expect that actually adding
them would get objection, but technically, is it what you are after?
--=20
Lawrence Crowl
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 27 Mar 2013 07:33:29 +0200
Raw View
On 27 March 2013 02:38, Lawrence Crowl <crowl@googlers.com> wrote:
> I was asking if adding deque::lock() deque::unlock() would meet
> the need, ignoring general wrappers. I expect that actually adding
> them would get objection, but technically, is it what you are after?
Here's a perhaps naive question: if I care about synchronizing
individual element pushes,
I will use a locking queue. If I don't, I will use a lock-free queue
and sync with
something else. Why would I use a locking queue for the latter case?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Jeffrey Yasskin <jyasskin@google.com>
Date: Wed, 27 Mar 2013 01:40:47 -0700
Raw View
On Tue, Mar 26, 2013 at 10:33 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 27 March 2013 02:38, Lawrence Crowl <crowl@googlers.com> wrote:
>> I was asking if adding deque::lock() deque::unlock() would meet
>> the need, ignoring general wrappers. I expect that actually adding
>> them would get objection, but technically, is it what you are after?
>
> Here's a perhaps naive question: if I care about synchronizing
> individual element pushes,
> I will use a locking queue. If I don't, I will use a lock-free queue
> and sync with
> something else. Why would I use a locking queue for the latter case?
Could you be more precise? "synchronizing" either refers to a very
specific relation defined in [intro.multithread], or it more
colloquially means "avoiding data races", or it implies something
complex. You have to do the second in C++, and lock-free queues are
just as good at establishing synchronizes-with relations as locked
queues, so you must mean the third, but I can't tell what the
"something complex" is.
Jeffrey
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 27 Mar 2013 10:56:08 +0200
Raw View
On 27 March 2013 10:40, Jeffrey Yasskin <jyasskin@google.com> wrote:
> On Tue, Mar 26, 2013 at 10:33 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> On 27 March 2013 02:38, Lawrence Crowl <crowl@googlers.com> wrote:
>>> I was asking if adding deque::lock() deque::unlock() would meet
>>> the need, ignoring general wrappers. I expect that actually adding
>>> them would get objection, but technically, is it what you are after?
>> Here's a perhaps naive question: if I care about synchronizing
>> individual element pushes,
>> I will use a locking queue. If I don't, I will use a lock-free queue
>> and sync with
>> something else. Why would I use a locking queue for the latter case?
> Could you be more precise? "synchronizing" either refers to a very
> specific relation defined in [intro.multithread], or it more
> colloquially means "avoiding data races", or it implies something
> complex. You have to do the second in C++, and lock-free queues are
> just as good at establishing synchronizes-with relations as locked
> queues, so you must mean the third, but I can't tell what the
> "something complex" is.
Pardon the misnomers, what I was after was blocking/waiting, I guess. What
I'm basically saying is that I find it hard to imagine a practical use
for a locking queue
that does multiple inserts, because in many of those cases I would
just use a separate
lock and a lockless queue. That doesn't mean bulk insertion operations
are useless
for a locking queue, I just have a feeling it's a corner case.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 27 Mar 2013 13:15:32 +0100
Raw View
Le 27/03/13 09:56, Ville Voutilainen a =E9crit :
> On 27 March 2013 10:40, Jeffrey Yasskin <jyasskin@google.com> wrote:
>> On Tue, Mar 26, 2013 at 10:33 PM, Ville Voutilainen
>> <ville.voutilainen@gmail.com> wrote:
>>> On 27 March 2013 02:38, Lawrence Crowl <crowl@googlers.com> wrote:
>>>> I was asking if adding deque::lock() deque::unlock() would meet
>>>> the need, ignoring general wrappers. I expect that actually adding
>>>> them would get objection, but technically, is it what you are after?
>>> Here's a perhaps naive question: if I care about synchronizing
>>> individual element pushes,
>>> I will use a locking queue. If I don't, I will use a lock-free queue
>>> and sync with
>>> something else. Why would I use a locking queue for the latter case?
>> Could you be more precise? "synchronizing" either refers to a very
>> specific relation defined in [intro.multithread], or it more
>> colloquially means "avoiding data races", or it implies something
>> complex. You have to do the second in C++, and lock-free queues are
>> just as good at establishing synchronizes-with relations as locked
>> queues, so you must mean the third, but I can't tell what the
>> "something complex" is.
> Pardon the misnomers, what I was after was blocking/waiting, I guess. Wha=
t
> I'm basically saying is that I find it hard to imagine a practical use
> for a locking queue
> that does multiple inserts, because in many of those cases I would
> just use a separate
> lock and a lockless queue.
Yes, some applications could need a thread-safe queue that doesn't=20
provide wait facilities. The externally_locked helper class is there=20
just to force the locking by the user using the type system. Blocking=20
and waiting are orthogonal features. Blocking needs a mutex and waiting=20
needs conditions (which needs mutex).
A concurrent queue providing blocking and waiting facilities can be=20
defined with an interface that hides the lock - internal locking (as=20
N3533 does) or forcing the lock by the user - external locking (as the=20
design of this post does). Both approaches have its usage. The first is=20
closed and simple to use on the common cases, the second is open and=20
more complex to use, but let do more things.
> That doesn't mean bulk insertion operations
> are useless
> for a locking queue, I just have a feeling it's a corner case.
>
I agree that bulk insertion is a corner case, but IMO bulk extraction=20
operation are quite usual.
Best,
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Lawrence Crowl <crowl@googlers.com>
Date: Wed, 27 Mar 2013 13:40:00 -0700
Raw View
On 3/27/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> Le 27/03/13 09:56, Ville Voutilainen a =E9crit :
> > On 27 March 2013 10:40, Jeffrey Yasskin <jyasskin@google.com> wrote:
> > > On Mar 26, 2013 Ville Voutilainen <ville.voutilainen@gmail.com> wrote=
:
> > > > On 27 March 2013 02:38, Lawrence Crowl <crowl@googlers.com> wrote:
> > > > > I was asking if adding deque::lock() deque::unlock() would
> > > > > meet the need, ignoring general wrappers. I expect that
> > > > > actually adding them would get objection, but technically,
> > > > > is it what you are after?
> > > >
> > > > Here's a perhaps naive question: if I care about
> > > > synchronizing individual element pushes, I will use a locking
> > > > queue. If I don't, I will use a lock-free queue and sync
> > > > with something else. Why would I use a locking queue for
> > > > the latter case?
> > >
> > > Could you be more precise? "synchronizing" either refers to
> > > a very specific relation defined in [intro.multithread],
> > > or it more colloquially means "avoiding data races", or
> > > it implies something complex. You have to do the second in
> > > C++, and lock-free queues are just as good at establishing
> > > synchronizes-with relations as locked queues, so you must mean
> > > the third, but I can't tell what the "something complex" is.
> >
> > Pardon the misnomers, what I was after was blocking/waiting,
> > I guess. What I'm basically saying is that I find it hard to
> > imagine a practical use for a locking queue that does multiple
> > inserts, because in many of those cases I would just use a
> > separate lock and a lockless queue.
>
> Yes, some applications could need a thread-safe queue that doesn't
> provide wait facilities. The externally_locked helper class
> is there just to force the locking by the user using the type
> system. Blocking and waiting are orthogonal features. Blocking
> needs a mutex and waiting needs conditions (which needs mutex).
>
> A concurrent queue providing blocking and waiting facilities
> can be defined with an interface that hides the lock - internal
> locking (as N3533 does) or forcing the lock by the user - external
> locking (as the design of this post does). Both approaches have its
> usage. The first is closed and simple to use on the common cases,
> the second is open and more complex to use, but let do more things.
Just to be clear, there are three cases, not two: external locking,
internal locking, and no locking. N3533 provides a single concept
for the last two cases, and an implementation for each of them.
I think the locking helper is a good idea, but I don't think it
replaces N3533 and its like because it is inherently locking.
> > That doesn't mean bulk insertion operations are useless for a
> > locking queue, I just have a feeling it's a corner case.
>
> I agree that bulk insertion is a corner case, but IMO bulk
> extraction operation are quite usual.
--=20
Lawrence Crowl
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 27 Mar 2013 22:47:45 +0100
Raw View
Le 27/03/13 21:40, Lawrence Crowl a =E9crit :
> On 3/27/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
>> A concurrent queue providing blocking and waiting facilities
>> can be defined with an interface that hides the lock - internal
>> locking (as N3533 does) or forcing the lock by the user - external
>> locking (as the design of this post does). Both approaches have its
>> usage. The first is closed and simple to use on the common cases,
>> the second is open and more complex to use, but let do more things.
> Just to be clear, there are three cases, not two: external locking,
> internal locking, and no locking. N3533 provides a single concept
> for the last two cases, and an implementation for each of them.
>
> I think the locking helper is a good idea, but I don't think it
> replaces N3533 and its like because it is inherently locking.
Agreed. I was not talking of lock free queues.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.