From mboxrd@z Thu Jan  1 00:00:00 1970
From: malte.vesper@postgrad.manchester.ac.uk (Malte Vesper)
Date: Fri, 30 Jan 2015 15:23:10 +0000
Subject: spinlock variable protection
In-Reply-To: <CAJs94EZK6PAT6RbkuAvJgdNce_6WananEJ06NAC6vJirro1hMw@mail.gmail.com>
References: <mafu9s$mhn$1@ger.gmane.org>	<A827E844-3767-4BE6-A45F-B3E1CC615E36@gmail.com>
	<CAJs94EZK6PAT6RbkuAvJgdNce_6WananEJ06NAC6vJirro1hMw@mail.gmail.com>
Message-ID: <54CBA1DE.2040605@postgrad.manchester.ac.uk>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

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.
>