Re: [Xenomai-core] [Patch 5/7] Define new syscalls for the system skin

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Gilles Chanteperdrix wrote:
 > On Mon, May 19, 2008 at 2:56 PM, Philippe Gerum <rpm@xenomai.org> wrote:
 > > Gilles Chanteperdrix wrote:
 > >> Philippe Gerum wrote:
 > >>  > Gilles Chanteperdrix wrote:
 > >>  > > As far as I understood, the user-space atomic operations, used to
 > >>  > > acquire a free mutex in user-space, are not part of the futex API. In
 > >>  > > our case, we are using xnarch_atomic_* operations to implement portably
 > >>  > > this user-space locking stuff. I think that even setting the bit saying
 > >>  > > that the mutex is currently owned is done in pthread_mutexes
 > >>  > > implementation, not in the Futex API.
 > >>  >
 > >>  > I would fully agree if the futex API did not define PI-based ops, which are
 > >>  > needed for proper real-time operations from userland. You will certainly agree
 > >>  > that PI implies that some kind of ownership exists; and because there can't be
 > >>  > more than a single owner in that case, you end up with an object that can't be
 > >>  > held by more than a single task. So you do have a mutex in disguise, whatever
 > >>  > the way to keep its state is (a bit, an integer, whatever). So there is stronger
 > >>  > semantics attached to that API than to simply manage an event notification scheme.
 > >>  >
 > >>  >  Now, what remains is
 > >>  > > sys_futex(FUTEX_WAIT) and sys_futex(FUTEX_WAKE), this terribly looks like
 > >>  > > xnsync_sleep_on and xnsynch_wakeup_one_sleeper.
 > >>  > >
 > >>  >
 > >>  > Yes, here again I partially agree, except for a significant issue: xnsynch is a
 > >>  > stateless object (that's why we can use it for different syncobjs which are
 > >>  > totally unrelated in their semantics - mutex, queue, region, counting sems,
 > >>  > whatever). I was just wondering if we could make the *tex thingy a bit more
 > >>  > stateful to ease the job for the skins, just in case we would use it for mutexes
 > >>  > only. I have no immediate answer to this question, just asking -- this is my
 > >>  > contribution as a senior member of the peanut gallery.
 > >>
 > >> We can certainly implement an abstraction managing xnarch_atomic_t +
 > >> xnsynch_t, however, it seems that we would have to re-factor all
 > >> mutex/semaphores implementations to use this new abstraction. The
 > >> current approach is to add an xnarch_atomic_cmpxchg in user-space, and
 > >> fall back to an almost unchanged kernel-space support when it fails.
 > >>
 > >
 > > Ok. Let's merge this as it is. Common code will emerge eventually if it happens
 > > to make sense when plugging the feature into the native and VxWorks mutex support.
 > 
 > Ok. I need a few more days though, to adapt it to other architectures than arm.

I changed my mind and commited the whole stuff. Instead of implementing
full atomic operations in user-space for other platforms than ARM, I
have left this work for others.

-- 


					    Gilles.