[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hurd-bug
Subject:    Re: [PATCH] ipc: perform conditional locking while changing the port sequence number
From:       Marin Ramesa <mpr () hi ! t-com ! hr>
Date:       2013-09-07 17:02:09
Message-ID: 1378573329.1822.0 () 00-1d-72-0b-97-8c ! sx76x ! gigaset ! net
[Download RAW message or body]

On 07.09.2013 10:46:18, Samuel Thibault wrote:
> Marin Ramesa, le Sat 07 Sep 2013 10:17:29 +0200, a écrit :
> > We have a local variable mqueue that is set by the lock, but if you 
> > look at the definition of imq_unlock() and then simple_unlock()
> > members of mqueue just change state and they don't have any effect 
> > on any other variable,
> 
> Sure, that is what usually happens for a locking/unlocking primitive
> pair: its only purpose is to change the state of the lock, and the
> side effect is obtained simply because other portions of the code use 
> the same lock (imq_lock), to protect the same thing (the seqno).
> 
> > plus it's a local variable - I would understand the code if 
> > mqueue is more global, but it's not.
> 
> The local variable is simply used to store the queue associated with
> the port, in order to be able to unlock it.

I completely misunderstood the code and the simple locks. No patch is 
needed and there is no real bug. Sorry if I have taken up your time. My 
misunderstanding and GCC (ver. 4.7.2) set-but-unused warning about 
mqueue got me thinking that there's no real locking happening when 
MACH_SLOCKS is not defined. 

Also, thanks for the above quoted explanation.
[prev in list] [next in list] [prev in thread] [next in thread]