Semantics of container accessors

[Dmitry_Vyukov]

What are official semantics of TBB's container accessors now? Do they have to provide more than just access to object? At least their name suggests that they must provide only access to object, just like smart pointer or Java/C# object reference.

[Anton_M_Intel · Accepted solution]

Quoting - Dmitriy V'jukov

What are official semantics of TBB's container accessors now? Do they have to provide more than just access to object? At least their name suggests that they must provide only access to object, just like smart pointer or Java/C# object reference.

Now - is it current version? Please, see the reference:

Concurrent Access

Member classes const_accessor and accessor are called accessors. Accessors allow multiple threads to concurrently access pairs in a shared concurrent_hash_map. An accessor acts as a smart pointer to a pair in a concurrent_hash_map. It holds an implicit lock on a pair until the instance is destroyed or method release is called on the accessor.

Classes const_accessor and accessor differ in the kind of access that they permit.

I'd add that that having non-empty accessor for an item guarantees that this item can not be destroyed and deallocated concurrently.

[RafSchietekat]

That's too vague, not to say misleading about the current implementation: I'm sure Dmitriy has looked at the definition too and still felt the need to ask for clarification (my intuition for "accessor" is different than his, though).

[Dmitry_Vyukov]

Quoting - Anton Malakhov (Intel)

I'd add that that having non-empty accessor for an item guarantees that this item can not be destroyed and deallocated concurrently.

Hmmm... I'm still puzzled whether item can be concurrently removed from hash map or not...

[Alexey-Kukanov]

While being concurrently accessed, an item could be removed from the map, but not destroyed. I thought we discussed this a lot already in a couple of other threads, didn't we? :) If this does not answer your actual question, please elaborate on it.

[Dmitry_Vyukov]

Quoting - Alexey Kukanov (Intel)

While being concurrently accessed, an item could be removed from the map, but not destroyed. I thought we discussed this a lot already in a couple of other threads, didn't we? :) If this does not answer your actual question, please elaborate on it.

Yes, we were discussing it already. I just wanted explicit clarification whether my hash map:

http://software.intel.com/en-us/forums/showthread.php?t=60494

provides the same semantics as TBB's hash map or not.

I was in some doubt about it, because there was a statement by Raf Schietekat about my hash map:

I was thinking about the difficulties associated with departing from sequential consistency, and in the present context whether it should be allowed to have N>1 different accessors to an object with key K in one map M all refer to private copies because "delete" doesn't want to wait anymore.

http://software.intel.com/en-us/forums/showthread.php?t=60494reply/63902/

If I get you correctly then current TBB's hash map provides the same semantics as mine, i.e. it's possible that a number of threads work with different "versions" of object referring to the same key. Right?