Michael Schnell wrote:
> Jamie Lokier wrote:
> > You can't implement futex just by touching bits in a processor
> > register - the whole point of futex is to have lots of different
> > memory locations representing different locks.
>
> You can do a single (or a few) FUTEX using "processor bits". This done
> you can use this dedicated FUTEX to create a critical section that
> protects whatever "atomic operations" are necessary to do the "real"
> Futexes.
Clever. That's going in my algorithms file.
If you have lots of processes running, it'll suffer from scheduling
contention on those occasions when an interrupt happens during the
critical section and causes reschedule(). The process will sleep, and
no other process will be able to do any futex operation until that
process runs again. But maybe that won't be too bad.
> > However if you can implement a "conditional-store" which depends on a
> > custom flag, you can clear the flag on interrupt entry or exit in the
> > kernel.
>
> I doubt that I can do this.
>
> Custom instructions can't access the memory (well in fact thy can but
> the need to use an additional bus interface that is on the other side of
> the CPU's cache). Moreover the condition for a failing operation would
> be either access to the said memory location or the occurrence of an
> interrupt. Neither can be detected by the "hardware" that implements the
> custom instruction. (OK, you can use an additional custom instruction
> that sets the flag you mention, and execute same it in the general ISR.)
Yes, other variations on 'nasty' hacks in the ISR entry/exit path include:
- Set a custom flag in userspace prior to load; ISR modifies a
specific register (the address) when it sees the flag is set and
returning to userspace.
- Set a custom flag in userspace prior to load; ISR modifies the
program counter on return to userspace by decrementing or
incrementing it by a fixed offset, or to a nearest multiple of
16/whatever.
- Set a custom register in userspace prior to the load; the value
is the program counter to jump to. ISR modifies the program
counter to that customer register's value (if set) when returning
to userspace.
- No custom hardware: Set a flag or PC value at a fixed memory
location accessible to userspace. The location could be set by
userspace with a system call, similar to set_thread_area().
- No custom hardware: Like the ARM method: Adjust PC when it's in a
specific range, which is fixed in the kernel; kernel tells
userspace the address of the cmpxchg routine at program startup.
- No custom hardware: Like the ARM method: Adjust PC when it's in a
specific range; userspace tells the kernel what the range is with
a system call, similar to set_thead_area(). Has the advantage
over the previous one that calls to the cmpxchg routine can be
direct jumps; one less memory reference.
-- Jamie
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
