On 04/23/2015 02:53 PM, Holger Hoffstätte wrote:
> On Thu, 23 Apr 2015 14:43:40 +0100, Filipe Manana wrote:
>
>> I don't think a lock followed by unlock without nothing in between (be
>> it a spinlock, mutex, or any other kind of lock) will be seen by the
>> compiler as a nop. Pretty sure I've seen this pattern being done in the
>
> No, I didn't say they would - that would be wrong. I just found it odd,
> that's all.
For reference, you have plenty of example in the kernel source tree:
$ find . -name '*.c' | xargs pcregrep --line-offsets -nrM
'^\s*spin_lock.*\n^\s*spin_unlock'
(...)
./fs/ext4/balloc.c:644:0,68
(...)
./mm/truncate.c:458:0,51
(...)
$ cat ./fs/ext4/balloc.c | head -646 | tail -4
if (!(*errp) && (flags & EXT4_MB_DELALLOC_RESERVED)) {
spin_lock(&EXT4_I(inode)->i_block_reservation_lock);
spin_unlock(&EXT4_I(inode)->i_block_reservation_lock);
dquot_alloc_block_nofail(inode,
$ cat ./mm/truncate.c | head -460 | tail -9
/*
* As truncation uses a lockless tree lookup, cycle
* the tree lock to make sure any ongoing tree
* modification that does not see AS_EXITING is
* completed before starting the final truncate.
*/
spin_lock_irq(&mapping->tree_lock);
spin_unlock_irq(&mapping->tree_lock);
>
>> kernel and in many other places as mechanism to wait for something.
>
> I also completely forgot that spinlocks disable preemption, since
> otherwise nothing would really work. That's the real reason why
> any of this works. Well, that and the refcount==2 thing.
>
> Cool! Thanks!
> Holger
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
