Atomic operations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I write in relation to a email I sent two weeks ago about atomicity.
Henrik, I have bought the book "Symmetric Multiprocessing and Caching
for Kernel Programmers" and it's great.

Anyway, what I am confused about is if this instruction is atomic:

if(flags & FLAG)
{
}

where flag is a constant such as 0x02. Is this atomic? The flags
variable is word-sized and hopefully aligned in its size boundary.

Now, my question is: If this is atomic, why are these kernel functions needed?

          test_bit()          --->  It ensures the operation is atomic
          __test_bit()      ----> It doesnt ensure atomicity

The book "Linux Kernel Development" by Robert Love says that i should
use this functions whenever i need to work with bits in a variable.
However, it seems more readable for me to use the classical way :

          flags |= FLAG                                    -->  to set a bit
          flags &= ~FLAG                                -->  to clear a bit
          (old_flags ^ new_flags) & FLAG        --> test if the flag has changed

...an so on. Of course, these last examples wouldnt be atomic, right?
Because it's not just reading the flags variable. Instead, it envolves
read-modify-write the variable. So I should use a locking scheme for
this.

But, if I assure there is one and only one writer (using a spinlock,
semaphore, ...) and use the above instructions to set/clear/change
bits is the (flags & FLAG) condition atomic? And why the need for
test_bit and __test_bit()?

Well, I hope my questions are clear, and someone can help me. I know,
I could just use test_bit() and forget about this. But, however, the
networking code uses flags the other way, for example in
dev_change_flags()  [net/core/dev.c].

It acquires the rtnl semaphore (in function dev_ioctl) before changing
anything in dev->flags, so there is no more than one writer at a
certain time. But in dev_get_flags() [net/core/dev.c] it reads the
flags, without acquiring any lock for that purpose.

Thank you for your time.
Regards

Aritz
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux