On Thu, 2006-12-07 at 00:03 +0100, Jan Kiszka wrote:
> Dmitry Adamushko wrote:
> > Hello,
> >
> > following the recent discussion with Jan, here is a patch that aims at
> > allowing xnintr_lock/unlock actually do what they were supposed to do in
> > the first instance.
> >
>
> [...]
>
> >
> >
Dmitry Adamushko wrote:
> Hello,
>
> following the recent discussion with Jan, here is a patch that aims at
> allowing xnintr_lock/unlock actually do what they were supposed to do in
> the first instance.
>
[...]
>
> --- xenomai/ksrc/nucleus/intr-old.c 2006-11-12 00:17:56.0 +0100
> +
I see two paths now:
A) If we go for atomic_inc/dec with such locking service,
xnarch_memory_barrier__after_atomic_inc & friends will be needed anyway
and could be already introduced now.
Yes, this would be better.
Any thoughts?
I have already sent once to you the message, but I do it n
Dmitry Adamushko wrote:
> ...
> In case of linux, smp_mb__after_atomic_inc() and
> smp_mb__before_atomic_dec()
> would do the job. But so far, I decided not to add something like
> xnarch_memory_barrier__after_atomic_inc() :) , provided that both seem to
> end up being either mb() or barrier() at t
