[cpp-threads] High-level concurrency issues

[jseigh_cp00 at xemaps.com]

Herb Sutter wrote:

>
>
>Peter wrote:
>
>
>>What alternative model can avoid this issue? I eliminate lock-free
>>    
>>
>from
>  
>
>>consideration because it's very difficult to write correct lock-free
>>    
>>
>code.
>
>That is exactly the problem: We have no _general_ better answer today
>for dealing with mutable shared state. Locks are the status quo, they
>are the best solution we have, and they are seriously deficient.
>
>Let me mention some alternatives. Jim and I mentioned most of these in
>the Queue article, too:
>
>First, I agree lock-free isn't the answer, and never will be for the
>general case -- my usual sound bite is "lock-based programming is hard
>for experts to get right, and lock-free programming is hard for geniuses
>to get right." I can't see any way that lock-free programming will ever
>be suitable for 99% of all the world's C++ developers, and there are lot
>of experts near the top of that 99% that I still wouldn't trust (I
>certainly wouldn't write lock-free code myself if I can help it). And
>that's how hard it is just to write it correctly once -- I'm ignoring
>the issue that lock-free code isn't close to portable, and always needs
>to be reviewed when porting to a new target, and often even to new
>versions of the original hardware architecture. And it's ignoring also
>that few structures and algorithms are actually known to have lock-free
>or low-lock implementations. I wouldn't teach this to people because it
>might embolden them to try it (sorry, Andrei! :-) ).
>  
>

I think the api's need to be worked out first.  Right now it's analogous 
to people writing their
own ad hoc lock implementations and then claiming lock based programming 
isn't valid as
the lock implementations are unstable.  Also, most programmers won't be 
using the lower
level api's but higher level api's contructed from them such as a 
lock-free linked list or
other lock-free collections written by people who presumably know what 
they're doing.

Part of that api will be things like smart pointers.   I'll probably 
talk more about C++ pointer
abstraction later at some point.

>Second, one way to reduce mutable shared state is to use immutable
>state. Most modern string packages are based on immutable instances,
>which are thread-safe by construction. (Alas, basic_string need not
>apply, at least not without refit.)
>  
>
You'd have to define thread-safe.  Immutable doesn't mean the instance 
can't be deleted
so, for  example, refcounted immutable strings would need a release 
memory barrier when
dropping the string reference for architectures which allow stores to 
pass loads.

--
Joe Seigh