* spinlock variable protection
@ 2015-01-30 12:43 Matwey V. Kornilov
2015-01-30 13:52 ` buyitian
0 siblings, 1 reply; 7+ messages in thread
From: Matwey V. Kornilov @ 2015-01-30 12:43 UTC (permalink / raw)
To: kernelnewbies
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* spinlock variable protection
2015-01-30 12:43 spinlock variable protection Matwey V. Kornilov
@ 2015-01-30 13:52 ` buyitian
2015-01-30 14:20 ` Matwey V. Kornilov
0 siblings, 1 reply; 7+ messages in thread
From: buyitian @ 2015-01-30 13:52 UTC (permalink / raw)
To: kernelnewbies
> ? 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 7+ messages in thread
* spinlock variable protection
2015-01-30 13:52 ` buyitian
@ 2015-01-30 14:20 ` Matwey V. Kornilov
2015-01-30 15:23 ` Malte Vesper
2015-01-31 12:04 ` Nicholas Mc Guire
0 siblings, 2 replies; 7+ messages in thread
From: Matwey V. Kornilov @ 2015-01-30 14:20 UTC (permalink / raw)
To: 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 at jabber.ru
^ permalink raw reply [flat|nested] 7+ messages in thread
* spinlock variable protection
2015-01-30 14:20 ` Matwey V. Kornilov
@ 2015-01-30 15:23 ` Malte Vesper
2015-01-30 15:29 ` Matwey V. Kornilov
2015-01-31 6:23 ` Arun KS
2015-01-31 12:04 ` Nicholas Mc Guire
1 sibling, 2 replies; 7+ messages in thread
From: Malte Vesper @ 2015-01-30 15:23 UTC (permalink / raw)
To: kernelnewbies
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.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* spinlock variable protection
2015-01-30 15:23 ` Malte Vesper
@ 2015-01-30 15:29 ` Matwey V. Kornilov
2015-01-31 6:23 ` Arun KS
1 sibling, 0 replies; 7+ messages in thread
From: Matwey V. Kornilov @ 2015-01-30 15:29 UTC (permalink / raw)
To: kernelnewbies
Nice, thank you
30.01.2015 18:24 ???????????? "Malte Vesper" <
malte.vesper@postgrad.manchester.ac.uk> ???????:
> 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.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150130/d9af5564/attachment.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* spinlock variable protection
2015-01-30 15:23 ` Malte Vesper
2015-01-30 15:29 ` Matwey V. Kornilov
@ 2015-01-31 6:23 ` Arun KS
1 sibling, 0 replies; 7+ messages in thread
From: Arun KS @ 2015-01-31 6:23 UTC (permalink / raw)
To: kernelnewbies
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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 7+ messages in thread
* spinlock variable protection
2015-01-30 14:20 ` Matwey V. Kornilov
2015-01-30 15:23 ` Malte Vesper
@ 2015-01-31 12:04 ` Nicholas Mc Guire
1 sibling, 0 replies; 7+ messages in thread
From: Nicholas Mc Guire @ 2015-01-31 12:04 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-01-31 12:04 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-30 12:43 spinlock variable protection Matwey V. Kornilov
2015-01-30 13:52 ` buyitian
2015-01-30 14:20 ` Matwey V. Kornilov
2015-01-30 15:23 ` Malte Vesper
2015-01-30 15:29 ` Matwey V. Kornilov
2015-01-31 6:23 ` Arun KS
2015-01-31 12:04 ` Nicholas Mc Guire
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.