220 186 <693771da-5f3b-48a4-923f-f0f7fabbf4dd@isocpp.org> article Path: news.gmane.org!not-for-mail From: adrien courdavault Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Lock free fifo, stack Date: Thu, 15 Nov 2012 05:30:19 -0800 (PST) Lines: 194 Approved: news@gmane.org Message-ID: <693771da-5f3b-48a4-923f-f0f7fabbf4dd@isocpp.org> References: <8ea5f6a7-f498-45a8-8baa-099fec4e5530@isocpp.org> <51f92d9d-5865-4fbf-938d-1d87aaaa68df@isocpp.org> <067243b6-0385-4fd2-b71b-52ce55c31b20@isocpp.org> <-7447476526686364750@unknownmsgid> <469ead4d-ad8a-4ebd-9791-0a5865f9a3b8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_105_12201714.1352986219920" X-Trace: ger.gmane.org 1352986226 7748 80.91.229.3 (15 Nov 2012 13:30:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2012 13:30:26 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDTNJ6MCWUNRB3W4SOCQKGQEOADAW5Q@isocpp.org Thu Nov 15 14:30:37 2012 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f69.google.com ([209.85.213.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TYzWb-000723-3i for gclcip-std-proposals@m.gmane.org; Thu, 15 Nov 2012 14:30:33 +0100 Original-Received: by mail-yh0-f69.google.com with SMTP id 47sf3108530yhr.0 for ; Thu, 15 Nov 2012 05:30:22 -0800 (PST) Original-Received: by 10.236.141.237 with SMTP id g73mr742454yhj.12.1352986222128; Thu, 15 Nov 2012 05:30:22 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.62.169 with SMTP id z9ls268474qer.47.gmail; Thu, 15 Nov 2012 05:30:20 -0800 (PST) Original-Received: by 10.49.6.36 with SMTP id x4mr231931qex.30.1352986220955; Thu, 15 Nov 2012 05:30:20 -0800 (PST) In-Reply-To: X-Original-Sender: adrien59cadri@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:186 Archived-At: ------=_Part_105_12201714.1352986219920 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Yes indeed lock free !=3D wait free. And I need wait free solution. BTW thank you for the link. Thank you for the information about the boost lock free. I 've found the=20 page of pending libs, it says depending on Atomic. I have to check exaclty what is Boost Atomic, because I thought most of the= =20 problem could be solved using c++11 For now I would be happy to have lock free solutions with "try" actions to= =20 be able to manage the time limit myself. But it would truly be nice to have= =20 it too :) . Clearly as you say it would be hard to specify this. A policy based=20 solution sounds much nicer implementation than just specific containers=20 especially for the dynamic allocation or not. For the allocation I often implement this currently with fixed size=20 messages using pools for memory use optimization. That is a bit limited for a library of the STL ;) Best Adrien PS @gurus working on the std: I know this sounds griddy to want more STD=20 because so many great people are doing there best and I clearly would be=20 happy to help if I could. Le jeudi 15 novembre 2012 06:25:55 UTC+1, Tony V E a =E9crit : > > On Wed, Nov 14, 2012 at 4:30 PM, adrien courdavault=20 > > wrote:=20 > > Hi=20 > >=20 > > I did not know about this could you tell me which lib would implement= =20 > that=20 > > in the future ?=20 > >=20 > > Surprisingly enough it is (or will be) called Boost.Lockfree. It=20 > should be in Boost "real soon now" although it was waiting for=20 > Boost.Atomic to get in first. Googling should be able to find the=20 > latest version of it.=20 > > > Another thing I would like to mention is the need to have a standard=20 > > solution(s) for dynamic allocation without lock or lock free pools of= =20 > memory=20 > > which would also be thread safe obviously.=20 > > I Checked out the tlsf allocator idea, and the http://locklessinc.com/l= ib.=20 > > I don't know if this is thread safe.=20 > >=20 > > Yes lock-free allocation would be nice (but hard :-). I don't think=20 > Boost.Lockfree has that (yet). Depending on requirements, there could=20 > be a number of different implementation tradeoffs. ie whether your=20 > memory typically gets allocated/freed by the same thread, or allocated=20 > by one and freed by another.=20 > > > Anyway I think that the multimedia applications and critical performanc= e=20 > > applications are often using C++ and need wait free and thread safe=20 > > "wait free" is not the same as "lock free" by the way. "wait free" is=20 > harder (but nicer if you can get it). See=20 > http://en.wikipedia.org/wiki/Non-blocking_algorithm . Also note=20 > "obstruction free", which is probably the one most closely related to=20 > transactional memory (they both employ a "hope for the best"=20 > strategy).=20 > > > Yes, I'd like to see much of this in the standard, and the concurrency=20 > group is looking into it. Personally, I think one of the difficult=20 > tasks will be finding a way to specify constraints, and also to allow=20 > programmers to select different containers based on needs - ie a=20 > single consumer multi producer FIFO could be implemented with=20 > different trade-offs than a multi-consumer single producer, etc for=20 > other combinations (also fixed size vs dynamic, etc). Do these=20 > options become "policies" of the container template?=20 > > Tony=20 > --=20 ------=_Part_105_12201714.1352986219920 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi

Yes indeed lock free !=3D wait free. And I need wait free solutio= n.
BTW thank you for the link.

Thank you for the information abou= t the boost lock free. I 've found the page of pending libs, it says depend= ing on Atomic.
I have to check exaclty what is Boost Atomic, because I t= hought most of the problem could be solved using c++11 <atomic>
For now I would be happy to have lock free solutions with "try" actions t= o be able to manage the time limit myself. But it would truly be nice to ha= ve it too :) .

Clearly as you say it would be hard to specify this. = A policy based solution sounds much nicer implementation than just specific= containers especially for the dynamic allocation or not.
For the alloca= tion I often implement this currently with fixed size messages using pools = for memory use optimization.
That is a bit limited for a library of the = STL ;)


Best

Adrien

PS @gurus working on the std: I= know this sounds griddy to want more STD because so many great people are = doing there best and I clearly would be happy to help if I could.

Le jeudi 15 novembre 2012 06:25:55 UTC+1, Tony V E a =E9crit :On Wed, Nov 14, 2012 at 4:30 PM, adr= ien courdavault
<adrien...@gmail.com> wrote:
> Hi
>
> I did not know about this could you tell me which lib would implem= ent that
> in the future ?
>

Surprisingly enough it is (or will be) called Boost.Lockfree.  It
should be in Boost "real soon now" although it was waiting for
Boost.Atomic to get in first.  Googling should be able to find the
latest version of it.

> Another thing I would like to mention is the need to have a standa= rd
> solution(s) for dynamic allocation without lock or lock free pools= of memory
> which would also be  thread safe obviously.
> I Checked out the tlsf allocator idea, and the http://locklessinc.com/ lib.
> I don't know if this is thread safe.
>

Yes lock-free allocation would be nice (but hard :-).  I don't thi= nk
Boost.Lockfree has that (yet).  Depending on requirements, there c= ould
be a number of different implementation tradeoffs.  ie whether you= r
memory typically gets allocated/freed by the same thread, or allocated
by one and freed by another.

> Anyway I think that the multimedia applications and critical perfo= rmance
> applications are often using C++ and need wait free and thread saf= e

"wait free" is not the same as "lock free" by the way.  "wait free= " is
harder (but nicer if you can get it).  See
http://en.wikipedia.org/wiki/Non-blocking_algorithm . =  Also note
"obstruction free", which is probably the one most closely related to
transactional memory (they both employ a "hope for the best"
strategy).


Yes, I'd like to see much of this in the standard, and the concurrency
group is looking into it.  Personally, I think one of the difficul= t
tasks will be finding a way to specify constraints, and also to allow
programmers to select different containers based on needs - ie a
single consumer multi producer FIFO could be implemented with
different trade-offs than a multi-consumer single producer, etc for
other combinations (also fixed size vs dynamic, etc).  Do these
options become "policies" of the container template?

Tony

--
 
 
 
------=_Part_105_12201714.1352986219920-- .