lkml.org 
[lkml]   [2005]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: write barriers - Was: Re: [RFC][PATCH] problem of cont_prepare_write()
Anton Altaparmakov wrote:

> If I am setting two variables in sequence and it is essential that if a
> different cpu reads those variables it seems them updated in the same
> order as they were written in the C code do I need a write barrier in
> between the two? For example:
>
> ntfs_inode->allocated_size = 10;
> ntfs_inode->initilized_size = 10;

I believe so. You may also need to cast them as volatile to prevent the
compiler from reordering--can someone with more gcc knowledge than I
state definitively whether or not it is smart enough to not reorder
barriers?

> Should another CPU see initialized_size = 10 but allocated_size < 10 the
> ntfs driver will blow up in some places. So does that mean I need a
> write barrier, between the two?

As above.

You may also need a read barrier to ensure that they are not
speculatively loaded in the wrong order--could someone more knowledgable
than I comment on that?

> If yes, do I still need it if I wrap the two settings (and all accesses)
> with a spin lock? And in particular with a rw-spinlock? For example:
>
> write_lock_irqsave(&ntfs_inode->size_lock, flags);
> ntfs_inode->allocated_size = 10;
> ntfs_inode->initilized_size = 10;
> write_unlock_irqrestore(&ntfs_inode->size_lock, flags);
>
> Do I still need a write barrier or does the spinlock imply it already?

I believe the spinlock implies it.

> Thanks a lot in advance and apologies for the stupid(?) questions...

Not stupid. Concurrency is hard.

Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.066 / U:0.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site