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.

-- 
 Gilles

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

Reply via email to