[lkml]   [2004]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Fix the cpumask rewrite

On Sat, 26 Jun 2004, James Bottomley wrote:
> This might be correct for x86 and itanium, but it isn't for parisc where
> our bitmap operators don't take volatile pointers.

Why not? The thing is, the bitmap operators are supposed to work on
volatile data, ie people are literally using them for things like

while (test_bit(TASKLET_STATE_SCHED, &t->state));

and the thing is supposed to work.

Now, I personally am not a big believer in the "volatile" keyword itself,
since I believe that anybody who expects the compiler to generate
different code for volatiles and non-volatiles is pretty much waiting for
a bug to happen, but there are two cases where I think it's ok:

- in function prototypes to show that the function can take volatile data
(and not complain).

- as an arch-specific low-level implementation detail to avoid having to
use inline assembly just to load a value. Ie a _data_structure_ should
never be volatile, but it's ok to use a volatile pointer for a single

I believe the bitop functions fall under #1 - the function is clearly
supposed to handle the case of a volatile pointer, and if it is inlined,
the above endless while-loop must not just load the bit once and turn it
into an endless loop - it needs to re-load the thing every iteration.

> Since whether the bitmap operators are volatile or not is within the
> province of the architecture to decide,

I disagree. Why wouldn't they be volatile?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.076 / U:0.868 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site