All that is really required is an atomic exchange. Suppose 1 means taken, 0 means free. I do an exchange with a 1. If I got back a zero, it's mine.
On Fri, Aug 7, 2009 at 3:08 AM, Michael Schnell <mschn...@lumino.de> wrote: > Jim Donelson wrote: > > I am amazed that the base design did not have atomic instructions. > > I understand that with a (simple) "Load-Store-RISC" architecture CPU, > that performs one instruction per clock cycle, a lot of additional > hardware (which would reduce the maximum clock frequency) is necessary > to allow for instructions that do more than one memory access. So > implementing instructions that do atomic memory read-modify-write > actions is not really an option. > > My suggestion is to provide a simple user-mode-allowed "lock" > instruction that disables the global interrupt for the next three > instructions. I feel this should not introduce much hardware overhead > and provide for any kind of atomic behavior. > > If course it must be provided that a userspace program can't abuse this > and after the three instructions the interrupt is enabled even if > another "lock" instruction is found (a premature lock instruction before > - say - three more instructions are executed would be ignored). > > In a multi-Core environment this lock instruction could be enhanced to > additionally do an inter-processor bus lock (cache syncing is something > else that needs to be though of). > > -Michael > > > _______________________________________________ > 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 >
_______________________________________________ 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
