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.
Link Copied
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.
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.
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).
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...
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.
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?
For more complete information about compiler optimizations, see our Optimization Notice.