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 whether
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
According to Linux and the Intel spec, this prefix is not needed.
---
include/asm-x86/atomic_32.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/include/asm-x86/atomic_32.h
===
--- a/include/asm-x86/atomic_32.h
++
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
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
R=dnslookup T=remote_smtp: SMTP error from remote mailer after RCPT
> TO:: host mail.gna.org [88.191.250.46]: 550 rejected because
gmail.
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
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
> > R=dnslookup T=remote_smtp: SMTP error from remote mailer after RCPT
>> TO: [EMAIL PROTECTED]>:
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
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
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 w
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
> > R=dnslookup T=remote_smtp: SMTP error from remote mailer after RCPT
>> TO: [EMAIL PROTECTED]>:
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
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 pse
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_mu
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
>> >> R=dnslookup T=remote_smtp: SMTP error from remote mailer after RCP
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
>>> >>> R=dnslookup T=remote_smtp:
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
>>> >>> R=dnslookup T=remote_smtp:
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
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
>>>
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
>>> >>> R=dnslookup T=remote_smtp:
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
>>
21 matches
Mail list logo