What is the behaviour of boost::detail::atomic_count overflow? I realize that overflow for a signed long is undefined, but it is possible that each platform-specific atomic increment operator handles overflow in some documented way, which in sum would constitute a defined behaviour for atomic_count overflow. Documenting this behaviour (along with that of underflow, which is presumably the same) in the atomic_count documentation would be extremely helpful.
I would like to add some context to my previous question in case there is a better solution to my problem that bypasses the question. On Tue, Feb 23, 2010 at 11:46 AM, Narcoleptic Electron <narcoleptic.electron@gmail.com> wrote:
What is the behaviour of boost::detail::atomic_count overflow?
Consider a thread-safe, reference-counting base class for objects pointed to by intrusive pointer, implemented using atomic_count. The problem is that the reference count can overflow, and overflowing a signed long is undefined. My thought is that perhaps, since atomic_count is implemented on a platform-by-platform basis, the behaviour on each is defined and can be taken advantage of (i.e. to roll-back the overflow prior to throwing the exception). This would allow me to continue to use atomic_count::operator++ without requiring locking. Otherwise, it seems that I would need to lock to make "checking the value and either incrementing it or throwing" a single transaction. Alternatively, perhaps there is a better way to solve this problem that I haven't considered (possibly using undocumented atomic calls). Any suggestions would be greatly appreciated.
participants (1)
-
Narcoleptic Electron