220 176 article Path: news.gmane.org!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Lock free fifo, stack Date: Thu, 15 Nov 2012 00:25:53 -0500 Lines: 53 Approved: news@gmane.org Message-ID: 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: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1352957155 601 80.91.229.3 (15 Nov 2012 05:25:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2012 05:25:55 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCUZ5QWKNQIOF6MRQUCRUBB46JNGQ@isocpp.org Thu Nov 15 06:26:06 2012 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f70.google.com ([209.85.212.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TYrxl-0002FV-25 for gclcip-std-proposals@m.gmane.org; Thu, 15 Nov 2012 06:26:05 +0100 Original-Received: by mail-vb0-f70.google.com with SMTP id fo1sf1874697vbb.9 for ; Wed, 14 Nov 2012 21:25:54 -0800 (PST) Original-Received: by 10.224.186.20 with SMTP id cq20mr256435qab.8.1352957154726; Wed, 14 Nov 2012 21:25:54 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.127.177 with SMTP id nh17ls141213qeb.36.gmail; Wed, 14 Nov 2012 21:25:54 -0800 (PST) Original-Received: by 10.224.42.8 with SMTP id q8mr227990qae.77.1352957154098; Wed, 14 Nov 2012 21:25:54 -0800 (PST) Original-Received: by 10.224.42.8 with SMTP id q8mr227989qae.77.1352957154085; Wed, 14 Nov 2012 21:25:54 -0800 (PST) Original-Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by mx.google.com with ESMTPS id u15si3671028qct.178.2012.11.14.21.25.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 21:25:54 -0800 (PST) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 209.85.216.50 as permitted sender) client-ip=209.85.216.50; Original-Received: by mail-qa0-f50.google.com with SMTP id k1so1008029qaf.2 for ; Wed, 14 Nov 2012 21:25:54 -0800 (PST) Original-Received: by 10.49.82.113 with SMTP id h17mr10082qey.24.1352957153927; Wed, 14 Nov 2012 21:25:53 -0800 (PST) Original-Received: by 10.49.97.234 with HTTP; Wed, 14 Nov 2012 21:25:53 -0800 (PST) In-Reply-To: <469ead4d-ad8a-4ebd-9791-0a5865f9a3b8@isocpp.org> X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.216.50 as permitted sender) smtp.mail=tvaneerd@gmail.com; dkim=pass header.i=@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:176 Archived-At: On Wed, Nov 14, 2012 at 4:30 PM, adrien courdavault wrote: > Hi > > I did not know about this could you tell me which lib would implement 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 standard > 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 think Boost.Lockfree has that (yet). Depending on requirements, there could be a number of different implementation tradeoffs. ie whether your 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 performance > applications are often using C++ and need wait free and thread safe "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 difficult 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 -- .