Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Chris Thomasson
Date : Wed May 18 2005 09:41 pm

>>>Lock-free is NOT a 100% solution. (There have been fanatics who denied 
>>>that and made the whole thing look a bit unsavory...
>>
>> The old SenderX...  I have seen the light!
>
> Are you seriously claiming that "Chris Thomasson == SenderX"? Fascinating. 
> That would certainly explain some things...
>
> Huh. ;-)

:)

I have learned a lot.




>> I am finding that an effective marriage between lock-based and lock-free 
>> can provide optimal solutions for all sorts of well-known problems...
>>
>>>It's overly complicated for many simple jobs, though a lot of people are 
>>>working on packages (particularly C++ template libraries) to make it 
>>>easier and more portable.
>>
>> Yes. Once you get the required infrastructure up and running, hiding a 
>> lock-free algorithm behind a simple API can be relatively easy. As for 
>> portability, I still don't trust C compilers. They can reorder 
>> instructions under your nose. This is why I try to keep all of my 
>> lock-free code in externally assembled functions. This can limit the 
>> number of chances a C compiler has to screw you over:
>
> However, there are a lot of linkers that can do optimization and 
> restructing at LINK time, too.

Absolutely. Link time optimization can potentially destroy the correctness 
of my externally assembled functions...

;(




> A far better solution is a compiler that understands multithread 
> visibility rules and does the right thing in the first place. 
> Realistically, most C/C++ compilers are "close enough", though lock-free 
> certainly stretches the limits further than simple pthread ops. Still, the 
> atomic ops and fences tend to be call-outs or builtins (whether asm() or 
> more specialized) that the compiler will treat as call-outs, and that buys 
> you a lot if you're careful. Realistically, this may be almost as much as 
> using assembly code buys you -- and with better readability.

Your probably right, however...


> But then... to each their own paranoia, eh? I definitely understand "where 
> you're coming from".

Exactly.   ;)


> In this context, though, I prefer staying at the higher level where at all 
> possible... "trust... but verify". ;-)

:)


> I look forward to a standardized C++ concurrent memory model. A 
> standardized C++ threading API would be nice, too, if a useful model can 
> survive the compromises; but the memory model is what we absolutely need, 
> now.
>
>> http://groups-beta.google.com/group/comp.programming.threads/msg/423df394a0370fa6
>>
>> ;)

I am also looking forward to a standardized memory model. Unfortunately, I 
think it will be a while before its "ready for prime time". There are just 
to many cpu-specific ways to optimize memory visibility.

;(...


I am sure we can cook something up. We can start with Alex's atomic<> 
stuff...




>>>If you want to investigate the relationships (both cooperative and 
>>>adversarial) between lock-free and locked design strategies, google 
>>>through the archives of this newsgroup -- we've had some quite "lively" 
>>>discussions on that topic over the years. ;-)
>>
>>
>> The SenderX files?
>
> Catchy. I like it. ;-)

lol.   ;)




P.S.

Its nice to hear from you David. I am looking forward to purchasing your 
upcoming book......

:)

.