------=_Part_3401_33476556.1364988501346
Content-Type: text/plain; charset=ISO-8859-1


A quick thought re the use case where a concurrent queue requires reopening
once closed.

In my own concurrent queue & stack implementations they are given "not
closed" (i.e. !closed) state on construction, including move & copy
construction. The swap function swaps this closed state, thus to reopen a
closed concurrent queue/stack I can move construct it elsewhere then swap
that back in.

It's a simple solution using the mechanics of the language without having
to expose such corner case functionality to the interface. I call it corner
case because, for me & my usage, typically when a queue is closed it's part
of the destruction of the object containing it (e.g. an active object
implementation). If I did want to frequently close & reopen a queue (i.e.
pause the queue execution), then such functionality (again for me) would be
made part of the outer controlling scope of the concurrent queue/stack. I'm
happy with using these mechanics & keeping the actual concurrent
queue/stack interfaces leaner & more inline with other standard objects.

--

---
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.



------=_Part_3401_33476556.1364988501346
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>A quick thought re the use case where a concurrent queue requires reope=
ning once closed.<br><br>In my own concurrent queue &amp; stack implementat=
ions they are given "not closed" (i.e. !closed) state on construction, incl=
uding move &amp; copy construction. The swap function swaps this closed sta=
te, thus to reopen a closed concurrent queue/stack I can move construct it =
elsewhere then swap that back in.<br><br>It's a simple solution using the m=
echanics of the language without having to expose such corner case function=
ality to the interface. I call it corner case because, for me &amp; my usag=
e, typically when a queue is closed it's part of the destruction of the obj=
ect containing it (e.g. an active object implementation). If I did want to =
frequently close &amp; reopen a queue (i.e. pause the queue execution), the=
n such functionality (again for me) would be made part of the outer control=
ling scope of the concurrent queue/stack. I'm happy with using these mechan=
ics &amp; keeping the actual concurrent queue/stack interfaces leaner &amp;=
 more inline with other standard objects.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_3401_33476556.1364988501346--

.

On 4/3/13, dmb.youcangetme@googlemail.com wrote:
> A quick thought re the use case where a concurrent queue requires
> reopening once closed.
>
> In my own concurrent queue & stack implementations they are given
> "not closed" (i.e. !closed) state on construction, including move
> & copy construction.  The swap function swaps this closed state,
> thus to reopen a closed concurrent queue/stack I can move construct
> it elsewhere then swap that back in.

In my implementation, the queue is not swappable unless the elements
were swappable.  I didn't want to make that a constraint.

I'm unclear on where the closed state comes from on the swap.
You have a pre-closed queue somewhere?

> It's a simple solution using the mechanics of the language without
> having to expose such corner case functionality to the interface.
> I call it corner case because, for me & my usage, typically
> when a queue is closed it's part of the destruction of the
> object containing it (e.g. an active object implementation).
> If I did want to frequently close & reopen a queue (i.e.
> pause the queue execution), then such functionality (again for
> me) would be made part of the outer controlling scope of the
> concurrent queue/stack.  I'm happy with using these mechanics &
> keeping the actual concurrent queue/stack interfaces leaner &
> more inline with other standard objects.

That was our thinking initially, but we came up with use cases
for reopening a queue, and the implementation is dead simple.
It seemed like the feature paid for itself, particularly since
users that do not want to reopen a queue simply do not.

In any event, this change is one I want discussed at the meeting.

--
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.



.

------=_Part_3095_1323532.1365304906342
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, April 4, 2013 11:34:55 PM UTC+1, Lawrence Crowl wrote:


>    On 4/3/13, dmb.you...@googlemail.com <javascript:> wrote:
>    > The swap function swaps this closed state,
>
> > I'm unclear on where the closed state comes from on the swap. You have a
> pre-closed queue somewhere?
>
> Sorry, to clarify my wording here. I meant that the swap function swaps
the open/closed state, not specifically a closed state. The container being
open comes from construction, & being closed comes only from a close()
member function (or indirectly via swapping a container that had been
closed via close() already).


> > That was our thinking initially, but we came up with use cases for
> reopening a queue, and the implementation is dead simple. It seemed like
> the feature paid for itself, particularly since users that do not want to
> reopen a queue simply do not.
>


You're right, and having thought again briefly, close() is somewhat unique
to the container, it's logically paired with open(), so if closed is part
of the interface there's little issue with open() there too. It makes for
simpler usage and could avoid the pointer swapping that would have applied
to my initial suggestion. For my usage reopening wasn't a feature I saw any
need for, and certainly not frequently, hence seeking an idiom to provide
for it, without directly supporting it via the interface. Typically
standardisation has to tend toward a middle-ground & wider application of
usage then I do.

Best regards,

--

---
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.



------=_Part_3095_1323532.1365304906342
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, April 4, 2013 11:34:55 PM UTC+1, Lawrence Crowl wrote:=
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&nbsp;&nbsp; =
On 4/3/13, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"rZghacsu8wQJ">dmb.you...@googlemail.com</a> wrote:
<br>&nbsp;&nbsp; &gt; The swap function swaps this closed state,
<br><br>&gt; I'm unclear on where the closed state comes from on the swap.
You have a pre-closed queue somewhere?
<br>
<br></blockquote><div>Sorry, to clarify my wording here. I meant that the s=
wap function swaps the open/closed state, not specifically a closed state. =
The container being open comes from construction, &amp; being closed comes =
only from a close() member function (or indirectly via swapping a container=
 that had been closed via close() already).<br></div><div>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">&gt; That was our thinking initiall=
y, but we came up with use cases for reopening a queue, and the implementat=
ion is dead simple. It seemed like the feature paid for itself, particularl=
y since
users that do not want to reopen a queue simply do not.
<br>
&nbsp;</blockquote><div>&nbsp;</div><div>You're right, and having thought a=
gain briefly, close() is somewhat unique to the container, it's logically p=
aired with open(), so if closed is part of the interface there's little iss=
ue with open() there too. It makes for simpler usage and could avoid the po=
inter swapping that would have applied to my initial suggestion. For my usa=
ge reopening wasn't a feature I saw any need for, and certainly not frequen=
tly, hence seeking an idiom to provide for it, without directly supporting =
it via the interface. Typically standardisation has to tend toward a middle=
-ground &amp; wider application of usage then I do.<br><br>Best regards,<br=
><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_3095_1323532.1365304906342--

.