Re: [boost] [thread] Interest in a locking pointer and lockable concept

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-03-18 04:16:54

Anthony Williams <anthony_w.geo <at> yahoo.com> writes:

> Phil Endecott <spam_from_boost_dev <at> chezphil.org> writes:
> 
> > Anthony Williams wrote:
> > > The C++0x atomic<> template will work with any type that is "trivially 
> > > copy
> > > assignable and bitwise equality comparable", and it is intended that 
> > > operations
> > > are protected with a mutex where they cannot be done with atomic ops. The
> > > is_lock_free() member distinguishes the two cases. I would expect this to 
> > > cover
> > > many uses, though obviously you can't write atomic<list<int>>, since 
> > > list<> 
> > > is
> > > definitely not bitwise equality-comparable.
> > 
> > Why have the "trivially copy assignable and bitwise equality 
> > comparable" restriction, if using a mutex is an acceptable solution?
> 
> I don't know. I've been focusing on the use of specializations that really are
> atomic when I've been reading the papers. I'll raise the issue.

The response from Lawrence is that firstly, types that do satisfy these
restrictions can be lock-free on more platforms, and secondly if a type doesn't
satisfy these constraints then you're calling user code whilst holding a lock. I
think this is an important point, and it might be worth having a separate type
to highlight the distinction. For types that satisfy the current requirements,
you can't tell by use whether or not a lock is used, since the
externally-visible effects are the same, so users might not think about the
possible presence of a mutex, just that the ops are atomic (which is the idea).

For types that had user-written copy constructors or comparison operators, you
could potentially end up with deadlock, and race conditions, even though there's
a mutex --- e.g. if the comparison operator referenced global state which could
be accessed from elsewhere without the mutex.

If we have a separate synchronisable<T> type that always uses a mutex, the issue
is much more explicit, and people are more likely to check their code for such
problems. Of course, people will still make mistakes sometimes, but these will
be less common.

Anthony
--
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL