From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <5387617B.6030208@xenomai.org>
Date: Thu, 29 May 2014 18:34:03 +0200
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
MIME-Version: 1.0
References: <1401378135.12445.YahooMailNeo@web171606.mail.ir2.yahoo.com>
 <53875E0E.4080701@xenomai.org> <538760BE.4050309@xenomai.org>
In-Reply-To: <538760BE.4050309@xenomai.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Xenomai] rtdm_mutex_init on forge
List-Id: Discussions about the Xenomai project <xenomai.xenomai.org>
List-Unsubscribe: <http://www.xenomai.org/mailman/options/xenomai>,
 <mailto:xenomai-request@xenomai.org?subject=unsubscribe>
List-Archive: <http://www.xenomai.org/pipermail/xenomai/>
List-Post: <mailto:xenomai@xenomai.org>
List-Help: <mailto:xenomai-request@xenomai.org?subject=help>
List-Subscribe: <http://www.xenomai.org/mailman/listinfo/xenomai>,
 <mailto:xenomai-request@xenomai.org?subject=subscribe>
To: Philippe Gerum <rpm@xenomai.org>, Matthias Schneider <ma30002000@yahoo.de>, "xenomai@xenomai.org" <xenomai@xenomai.org>

On 05/29/2014 06:30 PM, Philippe Gerum wrote:
> On 05/29/2014 06:19 PM, Philippe Gerum wrote:
>> On 05/29/2014 05:42 PM, Matthias Schneider wrote:
>>> Hi all,
>>>
>>> I have a question about rtdm_mutex_init in forge. BUG_ON is
>>> triggered each time I create an rtdm_mutex. This seems to be
>>> due to a check in xnsynch_init, while apparently some
>>> implementation is still missing in rtdm_mutex_init():
>>>
>>> void rtdm_mutex_init(rtdm_mutex_t *mutex)
>>> {
>>>          spl_t s;
>>>
>>>          /* Make atomic for re-initialisation support */
>>>          xnlock_get_irqsave(&nklock, s);
>>>
>>>          xnsynch_init(&mutex->synch_base,
>>>                       XNSYNCH_PRIO | XNSYNCH_PIP | XNSYNCH_OWNER, NULL);
>>>
>>>          xnlock_put_irqrestore(&nklock, s);
>>> }
>>>
>>>
>>> void xnsynch_init(struct xnsynch *synch, int flags, atomic_long_t
>>> *fastlock)
>>> {
>>>          if (flags & XNSYNCH_PIP)
>>>                  flags |= XNSYNCH_PRIO | XNSYNCH_OWNER;  /*
>>> Obviously... */
>>>
>>>          synch->status = flags & ~XNSYNCH_CLAIMED;
>>>          synch->owner = NULL;
>>>          synch->cleanup = NULL;  /* Only works for PIP-enabled
>>> objects. */
>>>          synch->wprio = -1;
>>>          INIT_LIST_HEAD(&synch->pendq);
>>>
>>>          if (flags & XNSYNCH_OWNER) {
>>>                  BUG_ON(fastlock == NULL); // <---------- Obviously
>>> this is
>>>                                            //             always
>>> occurs for an
>>>                                            //             rtdm_mutex.
>>>                  synch->fastlock = fastlock;
>>>                  atomic_long_set(fastlock, XN_NO_HANDLE);
>>>          } else
>>>                  synch->fastlock = NULL;
>>> }
>>>
>>> At the moment I am not sure if the atomic_long_t counter needs be
>>> added to
>>> rtdm_mutex or the flags need to be changed. Thanks for your help,
>>>
>>
>> RTDM mutexes cannot and do not have to provide fast locking memory, the
>> assertion I have added to xnsynch_init() is broken. Will fix.
> 
> Yes, the intent was to acknowledge the fact that we know how to 
> implement fast locking on all supported arch, rtdm was overlooked. So 
> this spurious assertion builds on the wrong assumption that a NULL 
> fastlock cannot happen with priority inversion protected locks.
> 

Adding fastlock to RTDM mutexes looks possible, and would create a
lockless fast patch for them as well.

-- 
                                                                Gilles.