Input please...

I've created SharedMemory and Semaphore classes for multi-processing
with support for Windows and UNIX. Is anyone interested?

https://github.com/robinrowe/multiprocessing

Also features a fixed-size RingBuffer queue template that doesn't use
the heap. Is anyone interested in that?

Would like to hear about any similar efforts, what history there may be
of trying to standardize these types of components. Links appreciated.

Thank you!

Robin
--
Robin Rowe
Beverly Hills, California

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/84ce0721-ed7b-85cf-5434-1b8eb153ddab%40gmail.com.

.

------=_Part_405_1043024525.1545432464815
Content-Type: multipart/alternative;
 boundary="----=_Part_406_1289604571.1545432464815"

------=_Part_406_1289604571.1545432464815
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Friday, December 21, 2018 at 3:46:36 AM UTC-5, Robin Rowe wrote:
>
> Input please...=20
>
> I've created SharedMemory and Semaphore classes for multi-processing=20
> with support for Windows and UNIX. Is anyone interested?=20
>
> https://github.com/robinrowe/multiprocessing=20
>
> Also features a fixed-size RingBuffer queue template that doesn't use=20
> the heap. Is anyone interested in that?=20
>
> Would like to hear about any similar efforts, what history there may be=
=20
> of trying to standardize these types of components. Links appreciated.


Note that it's totally possible for other programmers to be interested in=
=20
your library work, and yet simultaneously for WG21 to be uninterested in=20
putting it into the C++ language *standard*.  Just so you have the right=20
frame for however this thread develops. :)

Your thread-unsafe RingBuffer is very similar in design to P0059=20
`ring_span`:
https://github.com/Quuxplusone/ring_view
https://github.com/WG21-SG14/SG14/blob/master/SG14/ring.h

Guy Davidson is still somewhat pursuing P0059 ring-buffer-related work, but=
=20
I'm not.

Ring-buffers are like Concepts or Modules: everyone wants "a standard=20
ring-buffer type," but everyone thinks it means something slightly=20
different, such that nobody would actually be happy with the finished=20
product. Should it be thread-safe or thread-unsafe? Should it own or not=20
own its buffer? Should it be resizeable (and thus heap-allocated and=20
allocator-aware) or statically sized in-place?
P0059R0 chose "thread-unsafe, owning, heap-allocated OR in-place" (via two=
=20
different library types). P0059R1 chose "thread-unsafe, non-owning." Your=
=20
library chooses "thread-unsafe, owning, in-place." Lawrence's Crowl's P0260=
=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0260r2.html>=20
chooses "thread-safe, owning, heap-allocated." And so on ad nauseam. This=
=20
is what makes standardizing a "ring-buffer type" so difficult: no two=20
people want the same solution, and yet, we don't really want to standardize=
=20
a million slightly different solutions, either.

You should consider posting on codereview.stackexchange.com to get specific=
=20
library feedback. I'll just make one review comment here: your ring-buffer=
=20
constructs all N of its `T` objects when the ring-buffer itself is=20
constructed, which means it can hold only types which are both=20
DefaultConstructible and Assignable. (CopyAssignable, because you haven't=
=20
bothered with move semantics. But you can/should go fix that.) This may or=
=20
may not be an obstacle to general-purpose use.

HTH,
=E2=80=93Arthur

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0ba51187-1ea5-4e75-978f-802f2d52cc59%40isocpp.or=
g.

------=_Part_406_1289604571.1545432464815
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 21, 2018 at 3:46:36 AM UTC-5, Robin Ro=
we wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Input please...
<br>
<br>I&#39;ve created SharedMemory and Semaphore classes for multi-processin=
g=20
<br>with support for Windows and UNIX. Is anyone interested?
<br>
<br><a href=3D"https://github.com/robinrowe/multiprocessing" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com=
/url?q\x3dhttps%3A%2F%2Fgithub.com%2Frobinrowe%2Fmultiprocessing\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNERVuAKKT0UApCdvfhnkv8I3F0JPw&#39;;return true=
;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgithub.com%2Frobinrowe%2Fmultiprocessing\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNERVuAKKT0UApCdvfhnkv8I3F0JPw&#39;;return true;">https://github.com/=
robinrowe/<wbr>multiprocessing</a>
<br>
<br>Also features a fixed-size RingBuffer queue template that doesn&#39;t u=
se=20
<br>the heap. Is anyone interested in that?
<br>
<br>Would like to hear about any similar efforts, what history there may be=
=20
<br>of trying to standardize these types of components. Links appreciated.<=
/blockquote><div><br></div><div>Note that it&#39;s totally possible for oth=
er programmers to be interested in your library work, and yet simultaneousl=
y for WG21 to be uninterested in putting it into the C++ language <i>standa=
rd</i>. =C2=A0Just so you have the right frame for however this thread deve=
lops. :)</div><div><br></div><div>Your thread-unsafe RingBuffer is very sim=
ilar in design to P0059 `ring_span`:</div><div>https://github.com/Quuxpluso=
ne/ring_view<br></div><div>https://github.com/WG21-SG14/SG14/blob/master/SG=
14/ring.h<br></div><div><br></div><div>Guy Davidson is still somewhat pursu=
ing P0059 ring-buffer-related work, but I&#39;m not.</div><div><br></div><d=
iv>Ring-buffers are like Concepts or Modules: everyone wants &quot;a standa=
rd ring-buffer type,&quot; but everyone thinks it means something slightly =
different, such that nobody would actually be happy with the finished produ=
ct. Should it be thread-safe or thread-unsafe? Should it own or not own its=
 buffer? Should it be resizeable (and thus heap-allocated and allocator-awa=
re) or statically sized in-place?</div><div>P0059R0 chose &quot;thread-unsa=
fe, owning, heap-allocated OR in-place&quot; (via two different library typ=
es). P0059R1 chose &quot;thread-unsafe, non-owning.&quot; Your library choo=
ses &quot;thread-unsafe, owning, in-place.&quot; Lawrence&#39;s Crowl&#39;s=
 <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0260r2=
..html">P0260</a> chooses &quot;thread-safe, owning, heap-allocated.&quot; A=
nd so on ad nauseam. This is what makes standardizing a &quot;ring-buffer t=
ype&quot; so difficult: no two people want the same solution, and yet, we d=
on&#39;t really want to standardize a million slightly different solutions,=
 either.</div><div><br></div><div>You should consider posting on codereview=
..stackexchange.com to get specific library feedback. I&#39;ll just make one=
 review comment here: your ring-buffer constructs all N of its `T` objects =
when the ring-buffer itself is constructed, which means it can hold only ty=
pes which are both DefaultConstructible and Assignable. (CopyAssignable, be=
cause you haven&#39;t bothered with move semantics. But you can/should go f=
ix that.) This may or may not be an obstacle to general-purpose use.</div><=
div><br></div><div>HTH,</div><div>=E2=80=93Arthur</div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0ba51187-1ea5-4e75-978f-802f2d52cc59%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0ba51187-1ea5-4e75-978f-802f2d52cc59=
%40isocpp.org</a>.<br />

------=_Part_406_1289604571.1545432464815--

------=_Part_405_1043024525.1545432464815--

.

Arthur,

Thanks for catching me up on the history of previous ring queue attempts
and code links. Interesting. Very helpful!

Is there anyone who can also share what's come before for MP shared
memory and semaphores?

 > Just so you have the right frame for however this thread develops. :)

No expectations. I only seek to be useful.

 > Guy Davidson is still somewhat pursuing P0059 ring-buffer-related
 > work, but I'm not.

Guy, if you're available here, can you share your thoughts?

 > Ring-buffers are like Concepts or Modules: everyone wants "a standard
 > ring-buffer type," but everyone thinks it means something slightly
 > different, such that nobody would actually be happy with the finished
 > product. Should it be thread-safe or thread-unsafe?

Common practice suggests nobody sees a benefit to embedding locks in
containers generally. A container should be thread-unsafe or lockfree,
have external locks or not need locks. Because lockfree container
performance is so poor generally, slower than thread-unsafe containers
with external locks, let's set lockfree aside until we can show it works
better. That leaves just one choice: thread-unsafe.

 > Should it own or not own its buffer?

Because my ring buffer is in MP shared memory, it better own its data.

 > Should it be resizeable (and thus heap-allocated and
 > allocator-aware) or statically sized in-place?

The typical use-case for a ring queue is for a communications buffer
between threads or processes. We won't want that to be resizable or to
try heap allocations during a real-time service request. Moreover, if
for some reason we do decide we want a container like that, we already
have the resizable and heap-based std::queue.

 > Your library chooses "thread-unsafe, owning, in-place."

Yes, no other approach seems sensible for MP. With our use-case a comms
buffer, that must work in a multi-processing or multi-threaded
environment. To ensure not only the buffer but the apparatus of the
container are in shared memory, "owning and in-place" seem the only way
to go. Embracing the constraints of MP seems to force other slightly
different solutions to fall away.

 > You should consider posting on codereview.stackexchange.com to get
 > specific library feedback.

Thanks, implementation is still fresh. While I deeply appreciate your
feedback, I won't take the bandwidth of this list for code review. Will
follow up with you off-list.

The feedback I'm seeking now is opinions of whether this is the right
track toward a standard. Can this design overcome all the objections to
previous efforts to standardize a ring queue and MP shared memory?

https://github.com/robinrowe/multiprocessing

Thanks!

Robin
--
Robin Rowe
323-535-0952 mobile
Beverly Hills, California

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/992426dc-b7a7-2ffa-2937-8f362593c8e8%40gmail.com.

.

On 12/22/18 9:19 AM, Robin Rowe wrote:

> better. That leaves just one choice: thread-unsafe.
[...]
> The typical use-case for a ring queue is for a communications buffer
> between threads or processes. We won't want that to be resizable or to

In which case it should be thead-safe, no?

I agree that it should be thread-unsafe, because there are other use-
cases than interthread/-process communication, such as calculating the
running average on a sliding window. If we want a concurrent ring
buffer, then that could be added as a separate class -- or two, one for
threads and another for shared memory.

Some other proposals you may want to look at are P1135 "The C++20
Synchronization Library" [1] regarding semaphores, and the older N2044
"Memory Mapped Files and Shared Memory for C++" [2]. I do not think
there is any progress on the latter.

[1] http://wg21.link/P1135
]2] http://wg21.link/N2044

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8af98392-433f-eae6-9cb1-94ee1dd818ac%40mail1.stofanet.dk.

.

Bjorn,

Thanks for catching me up and the links. Very helpful!

 > Some other proposals you may want to look at are P1135 "The C++20
 > Synchronization Library" [1] regarding semaphores,
 > [1] http://wg21.link/P1135

Architecture seems to be multi-threaded, not multi-process, so not
comparable to my MP semaphore implementation.

Boost offers an MP semaphore:

#include <boost/interprocess/sync/interprocess_semaphore.hpp>

Any effort to standardize on interprocess_semaphore? Any other MP
semaphore efforts?

 > and the older N2044
 > "Memory Mapped Files and Shared Memory for C++" [2]. I do not think
 > there is any progress on the latter.
 > ]2] http://wg21.link/N2044

That's based on Boost shmem:

#include <boost/interprocess/shared_memory_object.hpp>
#include <boost/interprocess/mapped_region.hpp>

As the WG white paper points out, not portable across Windows and Linux.
Windows has a very limited shared memory API compared to UNIX. I have
tried, however, it's impossible to emulate the UNIX shared memory APIs
in Windows.

By the way, I'm the author of libunistd, the open source library that
implements the most popular bits of the POSIX, System V, BSD and
pthreads APIs in Windows:

https://github.com/robinrowe/libunistd

Typical Linux C++ code can be built in Windows Visual Studio by
including libunistd.

Robin
--
Robin Rowe
323-535-0952 mobile
Beverly Hills, California

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ec266a36-a589-1621-2b28-f523733f13ad%40gmail.com.

.

------=_Part_1129_516624203.1545606339251
Content-Type: multipart/alternative;
 boundary="----=_Part_1130_1456937605.1545606339252"

------=_Part_1130_1456937605.1545606339252
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Le vendredi 21 d=C3=A9cembre 2018 23:47:44 UTC+1, Arthur O'Dwyer a =C3=A9cr=
it :
>
>
> Ring-buffers are like Concepts or Modules: everyone wants "a standard=20
> ring-buffer type," but everyone thinks it means something slightly=20
> different, such that nobody would actually be happy with the finished=20
> product. Should it be thread-safe or thread-unsafe? Should it own or not=
=20
> own its buffer? Should it be resizeable (and thus heap-allocated and=20
> allocator-aware) or statically sized in-place?
> P0059R0 chose "thread-unsafe, owning, heap-allocated OR in-place" (via tw=
o=20
> different library types). P0059R1 chose "thread-unsafe, non-owning." Your=
=20
> library chooses "thread-unsafe, owning, in-place." Lawrence's Crowl's=20
> P0260=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0260r2.html>=20
> chooses "thread-safe, owning, heap-allocated." And so on ad nauseam. This=
=20
> is what makes standardizing a "ring-buffer type" so difficult: no two=20
> people want the same solution, and yet, we don't really want to standardi=
ze=20
> a million slightly different solutions, either.
>

About the thread-safety things, I recently came across the idea of taking a=
=20
policy as a template parameter (but haven't implemented it yet). The=20
possible policies would be something like exclusive_lock_policy,=20
rw_lock_policy or no_lock_policy for example.
just my 2 cents ;)

Masse Nicolas.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5defa165-d5bb-4306-aac7-3977edffbdbb%40isocpp.or=
g.

------=_Part_1130_1456937605.1545606339252
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br></div><div></div><br>Le vendredi 21 d=C3=A9cem=
bre 2018 23:47:44 UTC+1, Arthur O&#39;Dwyer a =C3=A9crit=C2=A0:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div>Ring-buffers are=
 like Concepts or Modules: everyone wants &quot;a standard ring-buffer type=
,&quot; but everyone thinks it means something slightly different, such tha=
t nobody would actually be happy with the finished product. Should it be th=
read-safe or thread-unsafe? Should it own or not own its buffer? Should it =
be resizeable (and thus heap-allocated and allocator-aware) or statically s=
ized in-place?</div><div>P0059R0 chose &quot;thread-unsafe, owning, heap-al=
located OR in-place&quot; (via two different library types). P0059R1 chose =
&quot;thread-unsafe, non-owning.&quot; Your library chooses &quot;thread-un=
safe, owning, in-place.&quot; Lawrence&#39;s Crowl&#39;s <a href=3D"http://=
www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0260r2.html" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpape=
rs%2F2017%2Fp0260r2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHyMWvADSJU=
D76_hhBrZ2NFr1No2w&#39;;return true;" onclick=3D"this.href=3D&#39;http://ww=
w.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2F=
docs%2Fpapers%2F2017%2Fp0260r2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NHyMWvADSJUD76_hhBrZ2NFr1No2w&#39;;return true;">P0260</a> chooses &quot;th=
read-safe, owning, heap-allocated.&quot; And so on ad nauseam. This is what=
 makes standardizing a &quot;ring-buffer type&quot; so difficult: no two pe=
ople want the same solution, and yet, we don&#39;t really want to standardi=
ze a million slightly different solutions, either.</div></div></blockquote>=
<div><br></div><div>About the thread-safety things, I recently came across =
the idea of taking a policy as a template parameter (but haven&#39;t implem=
ented it yet). The possible policies would be something like exclusive_lock=
_policy, rw_lock_policy or no_lock_policy for example.</div><div>just my 2 =
cents ;)</div><div><br></div><div>Masse Nicolas.<br></div><div><br></div></=
div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5defa165-d5bb-4306-aac7-3977edffbdbb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5defa165-d5bb-4306-aac7-3977edffbdbb=
%40isocpp.org</a>.<br />

------=_Part_1130_1456937605.1545606339252--

------=_Part_1129_516624203.1545606339251--

.

------=_Part_1032_2056600146.1545612474744
Content-Type: multipart/alternative;
 boundary="----=_Part_1033_1957855470.1545612474744"

------=_Part_1033_1957855470.1545612474744
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Monday, December 24, 2018 at 12:05:39 AM UTC+1, bounty killer wrote:
>
> Hi,
>
> Le vendredi 21 d=C3=A9cembre 2018 23:47:44 UTC+1, Arthur O'Dwyer a =C3=A9=
crit :
>>
>>
>> Ring-buffers are like Concepts or Modules: everyone wants "a standard=20
>> ring-buffer type," but everyone thinks it means something slightly=20
>> different, such that nobody would actually be happy with the finished=20
>> product. Should it be thread-safe or thread-unsafe? Should it own or not=
=20
>> own its buffer? Should it be resizeable (and thus heap-allocated and=20
>> allocator-aware) or statically sized in-place?
>> P0059R0 chose "thread-unsafe, owning, heap-allocated OR in-place" (via=
=20
>> two different library types). P0059R1 chose "thread-unsafe, non-owning."=
=20
>> Your library chooses "thread-unsafe, owning, in-place." Lawrence's Crowl=
's=20
>> P0260=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0260r2.html>=
=20
>> chooses "thread-safe, owning, heap-allocated." And so on ad nauseam. Thi=
s=20
>> is what makes standardizing a "ring-buffer type" so difficult: no two=20
>> people want the same solution, and yet, we don't really want to standard=
ize=20
>> a million slightly different solutions, either.
>>
>
> About the thread-safety things, I recently came across the idea of taking=
=20
> a policy as a template parameter (but haven't implemented it yet). The=20
> possible policies would be something like exclusive_lock_policy,=20
> rw_lock_policy or no_lock_policy for example.
> just my 2 cents ;)
>
> Masse Nicolas.
>
>
 How about adding new adapters like `std::stack`? Big advantage would be=20
that it could be used with current existing containers, disadvantage would=
=20
be that it can't have in every case best possible preformance. This could=
=20
be probably good start for thread safe containers. For basic need you use=
=20
adapter and when this part is performance critical you switch to some hand=
=20
written implementation or other specific thread safe container.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e0196adf-e43e-498b-bfd1-aa3721571648%40isocpp.or=
g.

------=_Part_1033_1957855470.1545612474744
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, December 24, 2018 at 12:05:39 AM UTC+1,=
 bounty killer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Hi,<br></div><div></div><br>Le vendredi 21 d=C3=A9cembre 2018=
 23:47:44 UTC+1, Arthur O&#39;Dwyer a =C3=A9crit=C2=A0:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><br><div>Ring-buffers are like Concept=
s or Modules: everyone wants &quot;a standard ring-buffer type,&quot; but e=
veryone thinks it means something slightly different, such that nobody woul=
d actually be happy with the finished product. Should it be thread-safe or =
thread-unsafe? Should it own or not own its buffer? Should it be resizeable=
 (and thus heap-allocated and allocator-aware) or statically sized in-place=
?</div><div>P0059R0 chose &quot;thread-unsafe, owning, heap-allocated OR in=
-place&quot; (via two different library types). P0059R1 chose &quot;thread-=
unsafe, non-owning.&quot; Your library chooses &quot;thread-unsafe, owning,=
 in-place.&quot; Lawrence&#39;s Crowl&#39;s <a href=3D"http://www.open-std.=
org/jtc1/sc22/wg21/docs/papers/2017/p0260r2.html" rel=3D"nofollow" target=
=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3d=
http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2=
Fp0260r2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHyMWvADSJUD76_hhBrZ2N=
Fr1No2w&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpape=
rs%2F2017%2Fp0260r2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHyMWvADSJU=
D76_hhBrZ2NFr1No2w&#39;;return true;">P0260</a> chooses &quot;thread-safe, =
owning, heap-allocated.&quot; And so on ad nauseam. This is what makes stan=
dardizing a &quot;ring-buffer type&quot; so difficult: no two people want t=
he same solution, and yet, we don&#39;t really want to standardize a millio=
n slightly different solutions, either.</div></div></blockquote><div><br></=
div><div>About the thread-safety things, I recently came across the idea of=
 taking a policy as a template parameter (but haven&#39;t implemented it ye=
t). The possible policies would be something like exclusive_lock_policy, rw=
_lock_policy or no_lock_policy for example.</div><div>just my 2 cents ;)</d=
iv><div><br></div><div>Masse Nicolas.<br></div><div><br></div></div></block=
quote><div><br></div><div>=C2=A0How about adding new adapters like `std::st=
ack`? Big advantage would be that it could be used with current existing co=
ntainers, disadvantage would be that it can&#39;t have in every case best p=
ossible preformance. This could be probably good start for thread safe cont=
ainers. For basic need you use adapter and when this part is performance cr=
itical you switch to some hand written implementation or other specific thr=
ead safe container.<br></div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e0196adf-e43e-498b-bfd1-aa3721571648%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e0196adf-e43e-498b-bfd1-aa3721571648=
%40isocpp.org</a>.<br />

------=_Part_1033_1957855470.1545612474744--

------=_Part_1032_2056600146.1545612474744--

.