------=_Part_238_1796561.1365351009874
Content-Type: text/plain; charset=ISO-8859-1

Does N3533 only describe unbounded queues? Why not provide two kinds of
concurrent queues: bounded_queue, unbounded_queue?

The size of elements in a unbounded_queue is not limited.
bounded_queue takes as ctor parameter a watermark describes the max.
elements in the bounded_queue so
that any call of push()-op would block the caller if this value is reached.
If the amount of elements is less than the watermark the caller (because
some other thread has poped some items) which is blocked in push()-op gets
unblocked.
Additionally the ctor of bounded_queue could take two watermarks:
high_water_mark = max. elements in the queue
low_watermark = the blocked caller in push()-op will only unblocked if the
amount of elements is less-or-equal to low_watermark
constraint: low_watermark <= high_watermark
I've some implementations of both kind of queues (boost.task and
boost.fiber) if it is of interest.

Oliver

--

---
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_238_1796561.1365351009874
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Does N3533 only describe unbounded queues? Why not provide two kinds of con=
current queues: bounded_queue, unbounded_queue?<br><br>The size of elements=
 in a unbounded_queue is not limited.<br>bounded_queue takes as ctor parame=
ter a watermark describes the max. elements in the bounded_queue so<br>that=
 any call of push()-op would block the caller if this value is reached.<br>=
If the amount of elements is less than the watermark the caller (because so=
me other thread has poped some items) which is blocked in push()-op gets un=
blocked.<br>Additionally the ctor of bounded_queue could take two watermark=
s:<br>high_water_mark =3D max. elements in the queue<br>low_watermark =3D t=
he blocked caller in push()-op will only unblocked if the amount of element=
s is less-or-equal to low_watermark<br>constraint: low_watermark &lt;=3D hi=
gh_watermark<br>I've some implementations of both kind of queues (boost.tas=
k and boost.fiber) if it is of interest.<br><br>Oliver<br><div style=3D"dis=
play: none;" id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"></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_238_1796561.1365351009874--

.

On 4/7/13, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
> Does N3533 only describe unbounded queues?  Why not provide two
> kinds of concurrent queues: bounded_queue, unbounded_queue?

The abstract concept admits both bounded and unbounded queues.
It's simply that unbounded queues will never return a full status.

The paper only provides a single concrete queue, and that one
is bounded.  It was my expectation that we would have more than
one concrete queue.

> The size of elements in a unbounded_queue is not limited.
> bounded_queue takes as ctor parameter a watermark describes
> the max.  elements in the bounded_queue so that any call of
> push()-op would block the caller if this value is reached.
> If the amount of elements is less than the watermark the caller
> (because some other thread has poped some items) which is blocked
> in push()-op gets unblocked.
>
> Additionally the ctor of bounded_queue could take two watermarks:
> high_water_mark = max. elements in the queue low_watermark =
> the blocked caller in push()-op will only unblocked if the
> amount of elements is less-or-equal to low_watermark constraint:
> low_watermark <= high_watermark I've some implementations of both
> kind of queues (boost.task and boost.fiber) if it is of interest.

Interesting.  Why did you need to have this second watermark?

I think the syntax of the abstract interface covers this behavior.
The real issue is whether or not it's guaranteed that the push
returns promptly.  There is a limit on how much promptness we can
legislate, but we can certainly make this distinction.  At present,
the text in N3533 does not specify promptness and would admit the
behavior you request.  However, I think that would surprise folks.
Another possibility is a weaker push that admits a delay.  Is it
worth the more complex interface?  I think we need to discuss the
idea at Bristol.

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



.

--001a11c1d39ad08b7c04d9e7398c
Content-Type: text/plain; charset=ISO-8859-1

2013/4/9 Lawrence Crowl <crowl@googlers.com>

> Interesting.  Why did you need to have this second watermark?
>

The second (low-)watermark enables slow consumers (dequeuing items)
do pop some items from the queue until fast producers push additional items.

1.) producers push items to queue
2.) high-watermark is reached and any additional push() would block the
producer
3.) slow consumers dequeue items
4.) blocked prociders are resumed if consumers have enough items dequeued
so that
     only low-watermark items are left in the queue

With only one watermark the producer is woken-up if one consumer has
dequeued one item -
something like a ping-pong.

--

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



--001a11c1d39ad08b7c04d9e7398c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013=
/4/9 Lawrence Crowl <span dir=3D"ltr">&lt;<a href=3D"mailto:crowl@googlers.=
com" target=3D"_blank">crowl@googlers.com</a>&gt;</span><br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
Interesting. =A0Why did you need to have this second watermark?<br></blockq=
uote></div><br></div><div class=3D"gmail_extra">The second (low-)watermark =
enables slow consumers (dequeuing items)<br></div><div class=3D"gmail_extra=
">
do pop some items from the queue until fast producers push additional items=
..<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
1.) producers push items to queue<br></div><div class=3D"gmail_extra">2.) h=
igh-watermark is reached and any additional push() would block the producer=
<br>
</div><div class=3D"gmail_extra">3.) slow consumers dequeue items<br></div>=
<div class=3D"gmail_extra">4.) blocked prociders are resumed if consumers h=
ave enough items dequeued so that<br></div><div class=3D"gmail_extra">=A0=
=A0=A0=A0 only low-watermark items are left in the queue<br>
<br></div><div class=3D"gmail_extra">With only one watermark the producer i=
s woken-up if one consumer has dequeued one item - <br></div><div class=3D"=
gmail_extra">something like a ping-pong.<br></div></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 />

--001a11c1d39ad08b7c04d9e7398c--

.