Gilles Chanteperdrix wrote:
 > On Mon, May 19, 2008 at 2:56 PM, Philippe Gerum <[EMAIL PROTECTED]> 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.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to