Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

Semantics of container accessors

Dmitry_Vyukov
Valued Contributor I
125 Views

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.

0 Kudos
1 Solution
Anton_M_Intel
Employee
125 Views
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.

View solution in original post

5 Replies
Anton_M_Intel
Employee
126 Views
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
Black Belt
125 Views

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
Valued Contributor I
125 Views

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_K_Intel3
Employee
125 Views

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
Valued Contributor I
125 Views

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?

Reply