220 167 <469ead4d-ad8a-4ebd-9791-0a5865f9a3b8@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: Wed, 14 Nov 2012 13:30:40 -0800 (PST) Lines: 300 Approved: news@gmane.org Message-ID: <469ead4d-ad8a-4ebd-9791-0a5865f9a3b8@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1062_21371949.1352928640130" X-Trace: ger.gmane.org 1352928647 17607 80.91.229.3 (14 Nov 2012 21:30:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Nov 2012 21:30:47 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDTNJ6MCWUNRBAM3SCCQKGQEAN7TWYY@isocpp.org Wed Nov 14 22:30:57 2012 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f198.google.com ([209.85.160.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TYkXr-0001kK-Qu for gclcip-std-proposals@m.gmane.org; Wed, 14 Nov 2012 22:30:52 +0100 Original-Received: by mail-gh0-f198.google.com with SMTP id g21sf1594227ghb.9 for ; Wed, 14 Nov 2012 13:30:41 -0800 (PST) Original-Received: by 10.58.233.38 with SMTP id tt6mr9402774vec.16.1352928641387; Wed, 14 Nov 2012 13:30:41 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.52.89.132 with SMTP id bo4ls1117665vdb.4.gmail; Wed, 14 Nov 2012 13:30:40 -0800 (PST) Original-Received: by 10.52.91.168 with SMTP id cf8mr657590vdb.6.1352928640792; Wed, 14 Nov 2012 13:30:40 -0800 (PST) In-Reply-To: <-7447476526686364750@unknownmsgid> 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:167 Archived-At: ------=_Part_1062_21371949.1352928640130 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi I did not know about this could you tell me which lib would implement that= =20 in the future ? 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 which would also be thread safe obviously. I Checked out the tlsf allocator idea, and the http://locklessinc.com/ lib.= =20 I don't know if this is thread safe. Anyway I think that the* multimedia applications and critical performance= =20 applications are often using C++ and need wait free and thread safe=20 solutions for containers AND allocation of the objects inside the container= s *. This is also important for game programming, and that is one of the=20 thing *that makes C++ so much more interesting than other languages but=20 coding that kind of stuff is hard, error prone. * Thank you for any informations you would have about this getting to be=20 standardized PS, I checked the transactional memory stuff it is not really clear to me= =20 yet but it looks like this may have applications in such things as lock=20 free, thread safe code but what I need is more the high level stuff=20 (containers and allocation) even if the implementation is not yet based on= =20 transactional memory. Best Le dimanche 11 novembre 2012 07:54:28 UTC+1, Tony V E a =E9crit : > > There are also lockfree structures currently making their way into boost. > > Sent from my BlackBerry=AE PlayBook=99 > www.blackberry.com > > ------------------------------ > *From:* "adrien courdavault" > > *To:* "std-pr...@isocpp.org " > > > *Sent:* 5 November, 2012 5:20 PM > *Subject:* [std-proposals] Re: Lock free fifo, stack > > Yes there is a non free commercial version indead. > > Le lundi 5 novembre 2012 22:48:21 UTC+1, DeadMG a =E9crit : >> >> I believe one of the study groups is a concurrency working group, which= =20 >> is looking at this. TBB is commercial, as well as GPL, I think. >> >> On Monday, November 5, 2012 9:38:38 PM UTC, adrien courdavault wrote: >>> >>> Thank you for the information. >>> When you say the standard is looking at it, do you mean it is already= =20 >>> studied by one of the groups ? >>> >>> I did not know about the PPL. >>> However I remember having a look at Intel's TBB but I think this is GPL= .. >>> >>> Best >>> >>> Le lundi 5 novembre 2012 22:19:27 UTC+1, DeadMG a =E9crit : >>>> >>>> The Standard is certainly looking at adding it. But you can find=20 >>>> high-quality implementations in TBB and PPL. >>>> >>>> On Monday, November 5, 2012 8:38:37 PM UTC, adrien courdavault wrote: >>>>> >>>>> *Hi everyone, >>>>> >>>>> I work in the domain of real-time audio processing. A problem that is= =20 >>>>> really common is to have a high priority thread (the audio device cal= lback)=20 >>>>> needing to send, receive messages or exchange data in general with ot= her=20 >>>>> thread (like the main application thread running the GUI). >>>>> >>>>> To do this I use Lock free FIFOs most of the time. The code I have=20 >>>>> for this is based on the publications of Herb Sutter among others. He= re is=20 >>>>> a list of interesting articles about this issue :=20 >>>>> http://globalengineer.wordpress.com/2008/10/31/lock-free-queue-articl= es-on-dr-dobbs-journal/ >>>>> >>>>> I=92m really happy to see the new feature, it is so nice=20 >>>>> because I will not have to write CompareAndSwapInt macros anymore to = have=20 >>>>> portable code between MacOS, and Windows (and soon perhaps Android, i= OS =85),=20 >>>>> that will clearly make my code simpler. Also I see that there is a gr= oup=20 >>>>> working hard on the transactional memory problem. And this is also=20 >>>>> important because I=92m not really good with the memory barriers issu= es but I=20 >>>>> had to code something using non-portable API to do create a multi wri= ter=20 >>>>> multi reader FIFO that is really thread safe on multi core architectu= res=20 >>>>> and I hope that the SG5 will make my life easier and this implementat= ion=20 >>>>> safer with more clean code. >>>>> >>>>> So I just wonder, why not adding lock free FIFO to the standard ? (As= =20 >>>>> I think I might not be the only one with this issue). And obviously t= his=20 >>>>> idea can be extended to more containers even if I don=92t think it wo= uld be=20 >>>>> useful for any container. >>>>> >>>>> In my search for existing libraries that are LGPL or other open=20 >>>>> licenses, I found this http://www.liblfds.org/, where there is such a= =20 >>>>> library without any license. >>>>> >>>>> Would you think this would be useful to have this ? >>>>> >>>>> Note : >>>>> I don=92t know if this is already included in any other proposal, I d= id=20 >>>>> not find this in the forum of future proposals and I don=92t think th= is is=20 >>>>> already a part of the standard nor the SG5 papers. >>>>> I=92m really sorry if I was wrong, if this already exist, could you= =20 >>>>> please tell me.* >>>>> >>>> --=20 > =20 > =20 > =20 > =20 --=20 ------=_Part_1062_21371949.1352928640130 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi

I did not know about this could you tell me which lib= would implement that in the future ?

Another thin= g I would like to mention is the need to have a standard solution(s) for dy= namic 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 th= read safe.

Anyway I think that the multimedia a= pplications and critical performance applications are often using C++ and n= eed wait free and thread safe solutions for containers AND allocation of th= e objects inside the containers. This is also important for game progra= mming, and that is one of the thing that makes C++ so much more interest= ing than other languages but coding that kind of stuff is hard, error prone= ..

Thank you for any informations you would have about this getti= ng to be standardized

PS, I checked the transactio= nal memory stuff it is not really clear to me yet but it looks like this ma= y have applications in such things as lock free, thread safe code but what = I need is more the high level stuff (containers and allocation) even if the= implementation is not yet based on transactional memory.

Best

Le dimanche 11 novembre 2012 07:54:28 UTC+1, Tony V E a= =E9crit :
There are = also lockfree structures currently making their way into boost.

Sent from my BlackBerry=AE PlayBook=99
www.blackberry.com

From: "adrien courdavault" <adrien..= ..@gmail.com>
To: "std-pr...@isocpp.org= " <std-pr...@isocpp.org>
Sent: 5 November, 2012 5:20 PM
Subject: [std-proposals] Re: Lock free fifo, stack

Yes there is a non= free commercial version indead.

Le lundi 5 novembre 201= 2 22:48:21 UTC+1, DeadMG a =E9crit :
I believe one of the study groups is a concurrency working group, which is = looking at this. TBB is commercial, as well as GPL, I think.

On Mond= ay, November 5, 2012 9:38:38 PM UTC, adrien courdavault wrote:
Thank you for the information.
When you say the standard is looking at = it, do you mean it is already studied by one of the groups ?

=
I did not know about the PPL.
However I remember havin= g a look at Intel's TBB but I think this is GPL.

Best

Le lundi 5 novembre 2012 22:19:27 UTC+1, De= adMG a =E9crit :
The Standard i= s certainly looking at adding it. But you can find high-quality implementat= ions in TBB and PPL.

On Monday, November 5, 2012 8:38:37 PM UTC, adrien courdavault wrote:Hi everyone,

I work in the do= main of real-time audio processing. A problem that is really common is to h= ave a high priority thread (the audio device callback) needing to send, rec= eive messages or exchange data in general with other thread (like the main = application thread running the GUI).

To do this I use= Lock free FIFOs most of the time. The code I have for this is based on= the publications of Herb Sutter among others. Here is a list of interestin= g articles about this issue : http://global= engineer.wordpress.com/2008/10/31/lock-free-queue-articles-on-dr-= dobbs-journal/

I=92m really hap= py to see the new <atomic> feature, it is so nice because I will not = have to write CompareAndSwapInt macros anymore to have portable code betwee= n MacOS, and Windows (and soon perhaps Android, iOS =85), that will clearly= make my code simpler. Also I see that there is a group working hard on the= transactional memory problem. And this is also important because I=92m not= really good with the memory barriers issues but I had to code something us= ing non-portable API to do create a multi writer multi reader FIFO that is = really thread safe on multi core architectures and I hope that the SG5 will= make my life easier and this implementation safer with more clean code.

So I just wonder= , why not adding lock free FIFO to the standard ? (As I think I might not b= e the only one with this issue). And obviously this idea can be extended to= more containers even if I don=92t think it would be useful for any contain= er.

In my search for= existing libraries that are LGPL or other open licenses, I found this http://www.liblfds.org/, where there is such a library without any license.<= br>
Would you think = this would be useful to have this ?

Note : I don=92t know if this is already included in any o= ther proposal, I did not find this in the forum of future proposals and I d= on=92t think this is already a part of the standard nor the SG5 papers.
I=92m really sorry if I was wrong, if this already exist, could you p= lease tell me.

--
 
 
 

--
 
 
 
------=_Part_1062_21371949.1352928640130-- .