Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Gilles Chanteperdrix wrote:
>>>>>>> Jan Kiszka wrote:
>>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>>> Jan Kiszka wrote:
>>>>>>>>>> Disabling SMP (on platforms where this isn't off by design already) 
>>>>>>>>>> is
>>>>>>>>>> an optimization. In contrast, not enabling it by default is doomed to
>>>>>>>>>> cause problems for users that run ./configure without looking into 
>>>>>>>>>> each
>>>>>>>>>> and every switch - now that CONFIG_SMP is very important for all the
>>>>>>>>>> fast locking stuff.
>>>>>>>>> I would consider setting CONFIG_SMP by default on x86... because on 
>>>>>>>>> some
>>>>>>>>> other architectures like arm, it is not even yet a valid 
>>>>>>>>> configuration.
>>>>>>>> But it is on PowerPC or IA64. Would it cause troubles for the
>>>>>>>> non-SMP-ready archs? Then we can disable it on those selectively.
>>>>>>> Are you sure that the lock prefix on an UP x86 or lsync on an UP powerpc
>>>>>>> is hamrless ?
>>>>>> LOCK is harmless (except for potential overhead), can't comment isync,
>>>>>> but I strongly suspect the same (locking at the glibc e.g.). There is a
>>>>>> simple idea behind this: Do you have to install a special glibc in order
>>>>>> to enable/disable SMP support?
>>>>>> [ BTW, I think the current pthread_mutex implementation lacks the LOCK
>>>>>> prefix even in SMP mode due to include issues. Will get fixed with my
>>>>>> patches under preparation, which also unifies that stuff on x86. ]
>>>>> Should be easy to check, disassemble pthread_mutex_lock with CONFIG_SMP
>>>>> enabled.
>>>>> You mean we should include asm/xenomai/features.h before using CONFIG_SMP 
>>>>> ?
>>>> That helps as well - I added xeno_config.h explicitly so far, but
>>>> features.h implies xeno_config.h, of course.
>>> asm/xenomai/features.h does convert the options into the
>>> kernel "namespace" options. But it seems that CONFIG_SMP is directly set
>>> by anyway.
>>>> Jan - who seems to have run into alignment issues of cmpxchg on x86_64
>>> pthread_mutex_lock uses xnheap_alloc to allocate the piece of memory
>>> used for the mutex. So, if the piece of memory is not eight bytes
>>> aligned, this is xnheap_alloc's fault...
>> Maybe it's far simpler: XNARCH_HAVE_US_ATOMIC_CMPXCHG - where the heck
>> does this come from? I just thought I only forgot to define it for
>> x86_64, but I don't find any traces for 32-bit as well. Hmm, should this
>> be called "CONFIG_XENO_FASTSEM" now? Testing...
> Yes, XNARCH_HAVE_US_ATOMIC_CMPXCHG is dead now, it was replaced with
> CONFIG_XENO_FASTSEM, in turn is set by Kconfig in kernel space, and
> in user-space.

Then this should fix fastsem support again (still preparing the

 ksrc/skins/posix/mutex.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

Index: b/ksrc/skins/posix/mutex.c
--- a/ksrc/skins/posix/mutex.c
+++ b/ksrc/skins/posix/mutex.c
@@ -97,11 +97,11 @@ int pse51_mutex_init_internal(struct __s
        shadow->mutex = mutex;
        shadow->lockcnt = 0;
        xnarch_atomic_set(&shadow->lock, -1);
        shadow->attr = *attr;
        shadow->owner_offset = xnheap_mapped_offset(&sys_ppd->sem_heap, ownerp);
        if (attr->protocol == PTHREAD_PRIO_INHERIT)
                synch_flags |= XNSYNCH_PIP;
@@ -163,16 +163,16 @@ int pthread_mutex_init(pthread_mutex_t *
                goto checked;
        err = pse51_mutex_check_init(shadow, attr);
        cb_read_unlock(&shadow->lock, s);
        if (err)
                return -err;
        if (err) {
                cb_read_unlock(&shadow->lock, s);
                return -err;
        mutex = (pse51_mutex_t *) xnmalloc(sizeof(*mutex));

Xenomai-core mailing list

Reply via email to