[Xenomai-core] Racy pse51_mutex_check_init?

Hi Gilles, trying to understand the cb_read/write lock usage, some question came up here: What prevents that the mutexq iteration in pse51_mutex_check_init races against pse51_mutex_destroy_internal? If nothing, then I wonder if we actually have to iterate over the whole queue to find out

Re: [Xenomai-core] [PATCH 2/2] Unify asm-x86/atomic.h

Gilles Chanteperdrix wrote: Jan Kiszka wrote: ...and also automatically fixes the missing LOCK prefix for pthread_mutex_* services on x86_32 SMP. This looks to me as a half-way unification. Can we not totally get rid of atomic_32.h and atomic_64.h ? I mean since we are using unsigned long

Re: [Xenomai-core] [PATCH] Remove redundant LOCK prefix

Jan Kiszka wrote: According to Linux and the Intel spec, this prefix is not needed. Obviously, it's not, since the whole purpose of xchg() is to guarantee bus locking for memory operands anyway. Please merge. --- include/asm-x86/atomic_32.h |2 +- 1 file changed, 1 insertion(+), 1

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Hi Jan, Please do not use my address at gmail, gna does not want me to post from this address: 2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org Xenomai-core@gna.org R=dnslookup T=remote_smtp: SMTP error from remote mailer after RCPT TO:Xenomai- [EMAIL PROTECTED]: host

Re: [Xenomai-core] [PATCH 2/2] Unify asm-x86/atomic.h

Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: ...and also automatically fixes the missing LOCK prefix for pthread_mutex_* services on x86_32 SMP. This looks to me as a half-way unification. Can we not totally get rid of atomic_32.h and atomic_64.h ? I mean since we are

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Gilles Chanteperdrix wrote: Hi Jan, Please do not use my address at gmail, gna does not want me to post from this address: 2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org Xenomai-core@gna.org R=dnslookup T=remote_smtp: SMTP error from remote mailer after RCPT TO:Xenomai-

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Jan Kiszka wrote: Hi Gilles, trying to understand the cb_read/write lock usage, some question came up here: What prevents that the mutexq iteration in pse51_mutex_check_init races against pse51_mutex_destroy_internal? If nothing, then I wonder if we actually have to iterate over the whole

Re: [Xenomai-core] [PATCH 2/2] Unify asm-x86/atomic.h

Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: ...and also automatically fixes the missing LOCK prefix for pthread_mutex_* services on x86_32 SMP. This looks to me as a half-way unification. Can we not totally get rid of atomic_32.h and

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Gilles, trying to understand the cb_read/write lock usage, some question came up here: What prevents that the mutexq iteration in pse51_mutex_check_init races against pse51_mutex_destroy_internal? If nothing, then I wonder if we actually

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Gilles, trying to understand the cb_read/write lock usage, some question came up here: What prevents that the mutexq iteration in pse51_mutex_check_init races against pse51_mutex_destroy_internal? If nothing, then I wonder

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Gilles, trying to understand the cb_read/write lock usage, some question came up here: What prevents that the mutexq iteration in pse51_mutex_check_init races against

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Gilles Chanteperdrix wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Gilles, trying to understand the cb_read/write lock usage, some question came up here: What prevents that the mutexq iteration in pse51_mutex_check_init races against

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi Jan, Please do not use my address at gmail, gna does not want me to post from this address: 2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org Xenomai-core@gna.org R=dnslookup T=remote_smtp: SMTP error from remote mailer

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi Jan, Please do not use my address at gmail, gna does not want me to post from this address: 2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org Xenomai-core@gna.org R=dnslookup T=remote_smtp: SMTP

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Jan Kiszka wrote: Gilles Chanteperdrix wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Gilles, trying to understand the cb_read/write lock usage, some question came up here: What prevents that the mutexq iteration in

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi Jan, Please do not use my address at gmail, gna does not want me to post from this address: 2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org Xenomai-core@gna.org

Re: [Xenomai-core] Racy pse51_mutex_check_init?

Jan Kiszka wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi Jan, Please do not use my address at gmail, gna does not want me to post from this address: 2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org Xenomai-core@gna.org R=dnslookup