spinlock variable protection
Hi, I have the following code int ret = 0; unsigned long irqflags; spin_lock_irqsave(&lock, irqflags); //... ret = hdl->count; //... spin_unlock_irqrestore(&lock, irqflags); return ret; I would like to be sure, that ret will not be optimized out. I think compiler can convert the code to equivalent: unsigned long irqflags; spin_lock_irqsave(&lock, irqflags); //... //... spin_unlock_irqrestore(&lock, irqflags); return hdl->count; But this is not what I want, because I use lock to protect hdl and want to return hdl->count value as it was in protected section.
在 2015年1月30日，20:43，"Matwey V. Kornilov" <matwey.kornilov@gmail.com> 写道：
Hi,
I have the following code
int ret = 0; unsigned long irqflags;
spin_lock_irqsave(&lock, irqflags);
//... ret = hdl->count; //...
spin_unlock_irqrestore(&lock, irqflags); return ret;
I would like to be sure, that ret will not be optimized out. I think compiler can convert the code to equivalent:
unsigned long irqflags;
spin_lock_irqsave(&lock, irqflags);
//... //...
spin_unlock_irqrestore(&lock, irqflags); return hdl->count;
But this is not what I want, because I use lock to protect hdl and want to return hdl->count value as it was in protected section.
Please check the assembly code to double confirm the GCC behavior. Why will GCC change the order as what you mentioned? Only assembly code can tell you.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
2015-01-30 16:52 GMT+03:00 buyitian <buyitian@gmail.com>:
Please check the assembly code to double confirm the GCC behavior. Why will GCC change the order as what you mentioned? Only assembly code can tell you.
It does not change at the moment. I think it can change it. Because from line ret = hdl->count; until line return ret; there is no access to either ret or hdl->count. So it is reasonable to optimizer to think that their values are the same and eliminate unneeded variable. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru
Spinlocks imply memory barriers as far as I am aware... Read here: http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt#L1634 On 30/01/15 14:20, Matwey V. Kornilov wrote:
2015-01-30 16:52 GMT+03:00 buyitian <buyitian@gmail.com>:
Please check the assembly code to double confirm the GCC behavior. Why will GCC change the order as what you mentioned? Only assembly code can tell you. It does not change at the moment. I think it can change it.
Because from line ret = hdl->count; until line return ret; there is no access to either ret or hdl->count. So it is reasonable to optimizer to think that their values are the same and eliminate unneeded variable.
Hi, On Fri, Jan 30, 2015 at 8:53 PM, Malte Vesper <malte.vesper@postgrad.manchester.ac.uk> wrote:
Spinlocks imply memory barriers as far as I am aware...
Read here: http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt#L1634
And may be here aswell, http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt#L1233 Thanks, Arun
On 30/01/15 14:20, Matwey V. Kornilov wrote:
2015-01-30 16:52 GMT+03:00 buyitian <buyitian@gmail.com>:
Please check the assembly code to double confirm the GCC behavior. Why will GCC change the order as what you mentioned? Only assembly code can tell you. It does not change at the moment. I think it can change it.
Because from line ret = hdl->count; until line return ret; there is no access to either ret or hdl->count. So it is reasonable to optimizer to think that their values are the same and eliminate unneeded variable.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Fri, 30 Jan 2015, Matwey V. Kornilov wrote:
2015-01-30 16:52 GMT+03:00 buyitian <buyitian@gmail.com>:
Please check the assembly code to double confirm the GCC behavior. Why will GCC change the order as what you mentioned? Only assembly code can tell you.
It does not change at the moment. I think it can change it.
Because from line ret = hdl->count; until line return ret; there is no access to either ret or hdl->count. So it is reasonable to optimizer to think that their values are the same and eliminate unneeded variable.
If your worry is that it will optimize it out then pack it into an ACCESS_ONCE and that should prevent GCC from doing so. for your case I think ret = ACCESS_ONCE(hdl->count); would be sufficient. thx! hofrat
participants (5)
-
Arun KS -
buyitian -
Malte Vesper -
Matwey V. Kornilov -
Nicholas Mc Guire