concurrent_unordered_map request
You mean lock free? Because if I understood well the updated containers with c++11 standard will be thread safe because of the definition of const. On 18 August 2013 22:35, Eugene Gordienko <egordienko@yahoo.com> wrote:
TBB and Microsoft have it. Why not to have it in boos?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Aug 20, 2013 at 9:06 PM, adrien courdavault < adrien.courdavault@gmail.com> wrote:
You mean lock free? Because if I understood well the updated containers with c++11 standard will be thread safe because of the definition of const.
const container objects can be accessed safely once constructed, but not non-const containers accessed through a const reference or pointer. My understanding is that this have nothing to do with the internal concurrency safety mechanism of standard containers. Anyway a lockfree associative container would be great and (if a stable and efficient thread-pool implementation was also available) would allow me to remove TBB from my dependencies. Joel Lamotte
On 20 August 2013 14:06, adrien courdavault <adrien.courdavault@gmail.com>wrote:
You mean lock free? Because if I understood well the updated containers with c++11 standard will be thread safe because of the definition of const.
No, they won't. The are "safe" in the sense that you can call non-modifying functions in different threads without synchronization as long as no one is calling a modifying function, but that really isn't the guarantee people are looking for when they want a "thread-safe" data structure. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
TBB and Microsoft have it. Why not to have it in boos?
I am in the middle of writing a suite of concurrent containers which I intend to submit to boost. Planned for inclusion are queue, stack, set, map, unordered set and unordered map, all in coarse grained and fine grained versions. The coarse grained versions are wrappers around the standard containers, but the fine grained versions are implemented from scratch. Coarse and fine grained versions share a common interface. If this is accepted, I would aim to add lock-free versions later. Nigel Pattinson On Wed, Aug 21, 2013 at 7:40 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
On 20 August 2013 14:06, adrien courdavault <adrien.courdavault@gmail.com
wrote:
You mean lock free? Because if I understood well the updated containers with c++11 standard will be thread safe because of the definition of const.
No, they won't.
The are "safe" in the sense that you can call non-modifying functions in different threads without synchronization as long as no one is calling a modifying function, but that really isn't the guarantee people are looking for when they want a "thread-safe" data structure. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Aug 20, 2013 at 11:45 PM, Nigel Pattinson < nigel.pattinson@kaseya.com> wrote:
Planned for inclusion are queue, stack, set, map, unordered set and unordered map, all in coarse grained and fine grained versions.
Does stack and queue implementation or features overlap with the lockfree implementations? I'll be interested in trying your libraries in my current project once you publish them for review. Joel Lamotte
Does stack and queue implementation or features overlap with the lockfree implementations?
I've only glanced at the lockfree versions, the implementations don't overlap but the features probably do. Nigel On Wed, Aug 21, 2013 at 12:34 PM, Klaim - Joël Lamotte <mjklaim@gmail.com>wrote:
On Tue, Aug 20, 2013 at 11:45 PM, Nigel Pattinson < nigel.pattinson@kaseya.com> wrote:
Planned for inclusion are queue, stack, set, map, unordered set and unordered map, all in coarse grained and fine grained versions.
Does stack and queue implementation or features overlap with the lockfree implementations?
I'll be interested in trying your libraries in my current project once you publish them for review.
Joel Lamotte
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (5)
-
adrien courdavault -
Eugene Gordienko -
Klaim - Joël Lamotte -
Nevin Liber -
Nigel Pattinson