220 41289 article Path: news.gmane.org!.POSTED!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Multi-processing SharedMemory, Semaphore and RingBuffer classes Date: Sun, 23 Dec 2018 16:47:54 -0800 (PST) Lines: 138 Approved: news@gmane.org Message-ID: References: <84ce0721-ed7b-85cf-5434-1b8eb153ddab@gmail.com> <0ba51187-1ea5-4e75-978f-802f2d52cc59@isocpp.org> <5defa165-d5bb-4306-aac7-3977edffbdbb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1032_2056600146.1545612474744" X-Trace: blaine.gmane.org 1545612351 17911 195.159.176.226 (24 Dec 2018 00:45:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Dec 2018 00:45:51 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBO6ZQDQQKGQEQVXFEZY@isocpp.org Mon Dec 24 01:45:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f200.google.com ([209.85.219.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gbENO-0004as-Kf for gclcip-std-proposals@m.gmane.org; Mon, 24 Dec 2018 01:45:46 +0100 Original-Received: by mail-yb1-f200.google.com with SMTP id v71sf1446524ybv.17 for ; Sun, 23 Dec 2018 16:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=8BKlqBV7KyxksSR9xCan0xmgslE23J626w5odtrdofI=; b=JsF0hiOkuaGnKOKTIP1b+m19k7kBF33eFgHoOtWsHmJaUxYRMsPjAAARmHzcGENMfA ixSPwSTJ/UqDNEW3dzgw9tK2TDYycQxa+KQHj238ElZquEnPHPII9m85b82MfRm4PUda WL1V++SlKWIz9A0Sm2xKFGke9p9dMUT8eJtuJXV6yhbWmTPvz2sR/0e7qTlb4tsrOUwO hHlwTc2WQlGw1qESrmdlcGYTXgiIyn2i5MZUaMGdtwl1VHoAnITkfOjbOgxsfkCm7iJk opGdrgMwUI4+/B+H/15nAR/BG/ANH6meR7WX7zHEFhH5apTUlOQ8hQgXcTgYV9XOxmzG 6DJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=8BKlqBV7KyxksSR9xCan0xmgslE23J626w5odtrdofI=; b=fiWYzIjz1caQB/V/Xlc0SSGI8uedNtsSvu3OGaUbrZf7kc5cP6cHnqTZBaWaL8I/bb Sn+SVKnucGZ96g/3ubom0R7tYnqO+Hwx+ms+TZN6Ksy8IWRRxwjRjDisETwBvfWUVy8Q HyLn/JBT9HVpXyt9cUWJa1w5kQvy85sv/pJExvWT/PMi+8soegS7t69fVZcQtmp5Fgw4 dnw2ECa2QNcoKMD0BgTezknZzd/ooQCt2JZbA5xzCBo8E31hiqKZoAlRCFeWXRywo8LT gJH22EetV1v4UiWe7P9KQj69w3EV8qG5SMrQ8Y00J4XUmpCftgoL8hUWC9KqyseYtKOr x3CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=8BKlqBV7KyxksSR9xCan0xmgslE23J626w5odtrdofI=; b=NHDlbj0bDYu3cdBSLKqNxzvEGettLDXm8t6GLfLLefKjxz+6+UZlzz3AuA8R6LtotD hm+se8xjBcehQuzs7q2r1YbCy60ZjPYfBPVKZXzxNhuo+MzeMFGO/ixUMAU9zeTvSiPf gW1d3I+XOg88QlshVxHA/D9MjJRAuO8MRvcVNoxovVM/KVf2d5TZKrd8ZUQ2zZIHdWBy FozH1tLZbf0MTp3HvuK5X3oj0NHnLy2JQ9LbY9Ioy07jYrpuMCOKKyp3Gr7KGMPxql1t wP9Ul/lNU1pTKPW5Uz277QyQIq5rWgx1uxLAR0IWSYqIvwbZC8r8yaIJD4SrfWtojnmL QKVQ== X-Gm-Message-State: AJcUukeZhbHBDksD6NgxY6i+FD+MLKC2P41aqgLJGsKXdZa5yg/WMRC0 JvbS1wIx1toHLYSp0HQtXQuznA== X-Google-Smtp-Source: ALg8bN60dWjOU5M9iyw+pxgiAI/yqU6A3cIvpvfJ4x8vvKCot0qnVyRDAB/U4m7vXh5gx3bSUgGPJQ== X-Received: by 2002:a25:48f:: with SMTP id 137mr1221657ybe.12.1545612476960; Sun, 23 Dec 2018 16:47:56 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:a105:: with SMTP id z5-v6ls3441282ybh.6.gmail; Sun, 23 Dec 2018 16:47:55 -0800 (PST) X-Received: by 2002:a25:9b44:: with SMTP id u4mr99716ybo.6.1545612475594; Sun, 23 Dec 2018 16:47:55 -0800 (PST) In-Reply-To: <5defa165-d5bb-4306-aac7-3977edffbdbb@isocpp.org> X-Original-Sender: inkwizytoryankes@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:41289 Archived-At: ------=_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 >> = =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


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=A9crit=C2=A0:

Ring-buffers are like Concept= s or Modules: everyone wants "a standard ring-buffer type," 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= ?
P0059R0 chose "thread-unsafe, owning, heap-allocated OR in= -place" (via two different library types). P0059R1 chose "thread-= unsafe, non-owning." Your library chooses "thread-unsafe, owning,= in-place." Lawrence's Crowl's P0260 chooses "thread-safe, = owning, heap-allocated." And so on ad nauseam. This is what makes stan= dardizing a "ring-buffer type" so difficult: no two people want t= he same solution, and yet, we don't really want to standardize a millio= n slightly different solutions, either.

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

Masse Nicolas.


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

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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.org.
------=_Part_1033_1957855470.1545612474744-- ------=_Part_1032_2056600146.1545612474744-- .