From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <483178FC.1010300@domain.hid> Date: Mon, 19 May 2008 14:56:28 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <18459.38249.462320.715909@domain.hid> <18459.38430.835407.942336@domain.hid> <18459.38500.720338.652195@domain.hid> <18459.38558.684426.240775@domain.hid> <18459.38644.699369.801548@domain.hid> <18459.38704.252719.734650@domain.hid> <48305BE4.3040503@domain.hid> <18480.30551.499645.920690@domain.hid> <48307F0A.5040206@domain.hid> <18480.34204.426031.862047@domain.hid> <4830A50D.8040507@domain.hid> <18480.45872.449093.746718@domain.hid> In-Reply-To: <18480.45872.449093.746718@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: Philippe Gerum Subject: Re: [Xenomai-core] [Patch 5/7] Define new syscalls for the system skin Reply-To: rpm@xenomai.org List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org 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. > > > > > > > > > > I feel this > > > > > would complicate things: currently, the way I implemented user-space > > > > > mutexes for the posix skin kept the old association between the > > > > > user-space mutex, and its kernel-space companion, also used by > > > > > kernel-space operations. > > > > > > > > > > > > > My concern boils down to: how much of the POSIX implementation, beyond the > > > > cb_lock stuff, would have to be duplicated to get the same support ported to, > > > > say the VxWorks semM services? > > > > > > The initialization code, and the additional calls to > > > xnarch_atomic_cmpxchg in user-space. If xnarch_atomic_cmpxchg fails we > > > call kernel-space, which is mostly unchanged. > > > > > > Because of the cb_lock stuff, I also needed to implement the > > > kernel-space syscalls in two versions: one if user-space has > > > xnarch_atomic_cmpxchg and could lock the mutex control block, the other > > > if the mutex control block needs to be locked by kernel-space. > > > > > > > This is the part my laziness would very much like to factor as much as possible. > > If ever possible. > > The current implementation is more or less: > > /* Common generic function */ > pse51_mutex_thing_inner(mutex) > { > /*... Assume mutex cb is locked ... */ > } > > /* Kernel-space operation */ > pthread_mutex_thing(mutex) > { > cb_trylock(mutex->lock); > > pse51_mutex_thing_inner(mutex); > > cb_unlock(mutex->lock); > } > > /* syscall wrapper */ > #ifdef XNARCH_HAVE_US_ATOMIC_CMPXCHG > __pthread_mutex_thing() > { > copy_from_user(); > > pse51_mutex_thing_inner(mutex) > > copy_to_user(); > } > #else > __pthread_mutex_thing() > { > copy_from_user(); > > pthread_mutex_thing(mutex) > > copy_to_user(); > } > #endif > > -- Philippe.