On Sunday 30 October 2011 17:45:18 Tim Blechmann wrote:
hi helge,
shared memory support: the fallback implementation relies on the spinlock pool that also used by the smart pointers. however this pool is per-process, so the fallback implementation won't work in shared memory. can this be changed/fixed?
fixing this would require a per-variable lock... depending on the platform this can have enormous overheads.
i've checked N3225, the most recent version of the draft that i have at hand at the moment. 29.4.4 tells me:
The implementation should not depend on any per-process state. This restriction enables communication by memory that is mapped into a process more than once and by memory that is shared between two processes.
cheers, tim
but "should" != "must", and additionally: a) IMHO atomics for inter-process coordination is the exception, while inter-thread coordination is the norm b) "per-object" lock is expensive (sizeof(pthread_mutex_t) can be 40 bytes) c) when you hit the fallback path, then you are better off using a datastructure with locking to begin with *If* I change the implementation to a per-object lock then this would in my view mean to optimize for an uncommon case, with noticable memory overhead penalties for the common case, to allow using the atomic objects as "drop-in" replacements in an environment where they are not the best solution anyways. (I would favor to move the distinction between using atomic objects for a given data structure versus locking upwards, instead of moving everything downwards and shoe-horning it into boost.atomic). I have serious difficulties justifying such a change, maybe others can offer their opinion? Best regards Helge