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 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 a given object has been initialized and >>>>>> registered already or not. Can't this be encoded differently? >>>>> We actually iterate over the queue only if the magic happens to be >>>>> correct, which is not the common case. >>>> However, there remains a race window with other threads removing other >>>> mutex objects in parallel, changing the queue - risking a kernel oops. >>>> And that is what worries me. It's unlikely. but possible. It's unclean. >>> Ok. This used to be protected by the nklock. We should add the nklock again. >> Well I do not think that anyone is rescheduling, so we could probably >> replace the nklock with a per-kqueue xnlock. > > If nklock or per queue - both will introduce O(n) at least local > preemption blocking. That's why I was asking for an alternative > algorithm than iterating over the whole list.
I insist: - the loop does almost nothing, so n will have to become very large for it to take a long time, and n is the number of mutexes allocated so far in one application, or the number of shared mutexes, which is probably even less. - the loop happens if the magic happens to be good, so probably only if you are calling pthread_mutex_init twice for the same mutex, the normal use-case is to use memory from BSS to allocate mutex, so the magic of a normal application calling pthread_mutex_init is always 0, and you do not enter the loop. Today, I consider it much more a problem that I can not call fork in a xenomai application with opened descriptors and exit the parent application without the file descriptors being closed in the child too. And this will be the thing I will spend time to fix first. Using the registry in the posix skin will only come next. -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core