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

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 wrote:

On 20 August 2013 14:06, adrien courdavault

...

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

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 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