[cpp-threads] High-level concurrency issues

[Boehm, Hans]

I agree.  That's basically what I had in mind as well.  Whenever we end
up calling into unknown code and run into a lock that is already held,
we are essentially also operating on an object that currently has a
broken invariant.  That's why the lock is presumably needed to start
with.

In single threaded code, you avoid the deadlock issues, etc., but you
still see the object with the broken state.  Which is arguably worse,
since the failure may be harder to detect.  (And transactional memory
seems to get us the single-threaded behavior here.)

Thus this really seems to amount to a great argument for functional
programming, but doesn't seem to have a lot to do with threads :-) .

So why do we usually associate these problems with threads?  Perhaps
it's just a quantitative issue?  With multiple threads around, a lot
more complex and unpredictable interactions are possible, and testing is
harder?  It's not just accidentally reaquiring a lock that breaks, it's
also accidentally acquiring locks in the wrong order, etc.

Hans

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Peter Dimov
> Sent: Tuesday, October 18, 2005 10:42 AM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] High-level concurrency issues
> 
> 
> Herb Sutter wrote:
> >> But
> >> in most cases, it seems to work tolerably well, and layers 
> of calls 
> >> seem to compose reasonably.  And I'm not 100% convinced that the 
> >> cases in which it breaks don't have single-threaded 
> lock-free analogs 
> >> in which I break object invariants with an unintentional recursive 
> >> call.
> >
> > I'd be interested to see analogs.
> 
> The general case is a class making an external call while one of its 
> invariants temporarily doesn't hold. Note that this is independent of 
> threads or locks. The lock case is a specific instance where 
> the invariant 
> is "no internal locks are held".
> 
> One simple example is
> 
>     v.insert( v.begin(), x );
> 
> where the vector can make an external call to the copy constructor or 
> assignment operator of X while being in an inconsistent state. 
> 
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>