This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Memory barriers vs lock/unlock


You're right, he certainly didn' t imply it was easy. As I recall he
only mentioned two techniques for avoiding locks, his RCU and hazard
pointers. Unfortunately they don't cover all the cases. In fact I got
the impression that they cover very *few* of the situations where locks
are needed. Getting rid of locks is the goal, but we're not there yet by
any means!

The Sutter article was interesting. Thanks for the link.

Paolo Carlini wrote:

>Kurt Kohler wrote:
>
>  
>
>>I don't supposed it's *that* much of a coincidence, but I was
>>considering mentioning that I heard Paul give a talk here in Corvallis a
>>few weeks ago. He talked about memory barriers (and locks) and
>>recommended against them because of their cost in time. I suspect he'd
>>approve of a solution that didn't use any.
>>
>>His basic premise (as I understand it) was that as processors become
>>faster, the time to do the real work in a critical section is getting
>>smaller and smaller compared to the price of locking (or memory
>>barriers). I think it would be fair to summarize his talk as "locks
>>considered harmful!"
>>
>>    
>>
>Yes, we know that, or, better said, Peter knows that very well. On the
>other hand, I suppose McKenney also explained that lock-free programming
>is hard, very hard at times. Herb Sutter wrote some nice jokes about
>this here:
>
>    http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=332
>
>We are all moving in that direction, anyway.
>
>Paolo.
>  
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]