lkml.org 
[lkml]   [2008]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] mdb: Merkey's Linux Kernel Debugger 2.6.27-rc4 released
Paul E. McKenney wrote:
> On Thu, Aug 21, 2008 at 01:02:48PM +0200, Peter Zijlstra wrote:
>> On Thu, 2008-08-21 at 12:57 +0200, Stefan Richter wrote:
>>> Peter Zijlstra wrote:
>>>> On Wed, 2008-08-20 at 20:50 -0600, jmerkey@wolfmountaingroup.com wrote:
>>>>
>>>>> volatiles left in the code due to the previously stated
>>>>> (and still present) severe breakage of the GNU compiler with SMP
>>>>> shared data. most of the barrier() functions are just plain broken
>>>>> and do not result in proper compiler behavior in this tree.
>>>> Can you provide explicit detail?
>>>>
>>>> By using barrier() the compiler should clobber all its memory and
>>>> registers therefore forcing a write/reload of the variable.
>>> I hope Jeff didn't try mere barrier()s only. smp_wmb() and smp_rmb()
>>> are the more relevant barrier variants for mdb, from what I remember
>>> when I last looked at it.
>> Sure, but volatile isn't a replacement for memory barriers.
>
> Let's face it, the C standard does not support concurrency, so we are
> all in a state of sin in any case, forced to rely on combinations of
> gcc-specific non-standard language extensions and assembly language.
>
> Could be worse!!!

Nevertheless, an analysis of which particular parts of code generation
are insufficient if one particular volatile qualification is removed is
IMO likely to turn up places in mdb where a clearer or/and more
efficient implementation is possible. (Based on what I saw a few
revisions ago; I haven't looked at the current one yet.)
--
Stefan Richter
-=====-==--- =--- =-=-=
http://arcgraph.de/sr/


\
 
 \ /
  Last update: 2008-08-21 14:15    [W:0.444 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site