Re: [uClinux-dev] Shell exits while running a program.
Amruta, While I can't say anything about the problem in question, I'd like to say that I also am starting porting a multithreaded application to Linux, so a discussion might be useful. Do you use MMU-based Linux or the noMMU Architecture ? Which kind of "posix semaphores" do you use ? I found that with my architecture (NIOS2) the FUTEX fastpath is not decently provided. As I saw in the Kernel sources, same seems to be true for Microblaze. Do you use a glibc that provides the FUTEX fastpath ? I found that, if no FUTEX fastpath is provided for an ARCH, the pthread_mutex... code automatically falls back to using inter-process semaphores (instead of fastpath userland inter-thread semaphores), which (on such a CPU) produces a 100 times more overhead in the (very likely) case that a semaphore is not already taken by another thread. So I suppose I'll do the Futex for the NIOS some day soon which very likely includes doing as well software as some HDL code. I did a testing program that times several implementations of semaphores and thus very heavily uses them. I never got any "shell exits". >From the standard libraries, I uses pthread_mutex... and System V "sema" in my testing program. -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
RE: [uClinux-dev] Shell exits while running a program.
Hi, I use a noMMU environment. I am using sem_init, sem_wait, sem_post for unnamed semaphores across threads. I don’t think the uClibc that I have supports futexes as there is a note in its TODO to add support for futexes. Thanks & regards, Amruta Bhat -Original Message- From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Michael Schnell Sent: Wednesday, August 05, 2009 3:33 PM To: uClinux development list Subject: Re: [uClinux-dev] Shell exits while running a program. Amruta, While I can't say anything about the problem in question, I'd like to say that I also am starting porting a multithreaded application to Linux, so a discussion might be useful. Do you use MMU-based Linux or the noMMU Architecture ? Which kind of "posix semaphores" do you use ? I found that with my architecture (NIOS2) the FUTEX fastpath is not decently provided. As I saw in the Kernel sources, same seems to be true for Microblaze. Do you use a glibc that provides the FUTEX fastpath ? I found that, if no FUTEX fastpath is provided for an ARCH, the pthread_mutex... code automatically falls back to using inter-process semaphores (instead of fastpath userland inter-thread semaphores), which (on such a CPU) produces a 100 times more overhead in the (very likely) case that a semaphore is not already taken by another thread. So I suppose I'll do the Futex for the NIOS some day soon which very likely includes doing as well software as some HDL code. I did a testing program that times several implementations of semaphores and thus very heavily uses them. I never got any "shell exits". From the standard libraries, I uses pthread_mutex... and System V "sema" in my testing program. -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
Re: [uClinux-dev] Shell exits while running a program.
Bhat, Amruta wrote: > Hi, > I use a noMMU environment. > I am using sem_init, sem_wait, sem_post for unnamed semaphores across threads. So I would try if pthread_mutex_lock() and pthread_mutex_unlock() works better. I suppose using the pthread... functions for all managing of threads is the most recommended way. Did you create the threads using pthread_create() ? > > I don’t think the uClibc that I have supports futexes as there is a note in > its TODO to add support for futexes. > If you use a noMMU architecture it might be quite easy to do the FUTEX, as you can disable and re-enable the global Interrupt in a userland application (at least with NIOS2-noMMU this is possible. But I suppose you need to recompile your glibC for this. -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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > > I don’t think the uClibc that I have supports futexes as there is > > a note in its TODO to add support for futexes. > > If you use a noMMU architecture it might be quite easy to do the FUTEX, > as you can disable and re-enable the global Interrupt in a userland > application (at least with NIOS2-noMMU this is possible. But I suppose > you need to recompile your glibC for this. MMU or not isn't relevant. Some noMMU architectures don't let you disable interrupts from userspace, and some MMU architectures do. What matters is: - Do you have atomic instructions. - Do you have one CPU or multiple CPUs. Let's assume you have a single CPU and no special atomic instructions. Then you can either: - Disable interrupts (like on NIOS-noMMU) for the fastpath operation, if that's possible. - Copy the trick used on ARM to implement atomic-compare-exchange in the vsyscall page, without disabling interrupts. The vsyscall trick is a good one, and works with/without MMU, and with/without permission to disable interrupts in userspace. It's fast too. I recommend reading the code. It's only a few instructions. -- 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
RE: [uClinux-dev] Shell exits while running a program.
Hi, Thanks for your inputs. I have single CPU and current version of it does not support atomic instructions :(. I'll check on the suggestions y Thanks & regards, Amruta Bhat -Original Message- From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Jamie Lokier Sent: Wednesday, August 05, 2009 11:13 PM To: uClinux development list Subject: Re: [uClinux-dev] Shell exits while running a program. Michael Schnell wrote: > > I don’t think the uClibc that I have supports futexes as there is > > a note in its TODO to add support for futexes. > > If you use a noMMU architecture it might be quite easy to do the FUTEX, > as you can disable and re-enable the global Interrupt in a userland > application (at least with NIOS2-noMMU this is possible. But I suppose > you need to recompile your glibC for this. MMU or not isn't relevant. Some noMMU architectures don't let you disable interrupts from userspace, and some MMU architectures do. What matters is: - Do you have atomic instructions. - Do you have one CPU or multiple CPUs. Let's assume you have a single CPU and no special atomic instructions. Then you can either: - Disable interrupts (like on NIOS-noMMU) for the fastpath operation, if that's possible. - Copy the trick used on ARM to implement atomic-compare-exchange in the vsyscall page, without disabling interrupts. The vsyscall trick is a good one, and works with/without MMU, and with/without permission to disable interrupts in userspace. It's fast too. I recommend reading the code. It's only a few instructions. -- 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 ___ 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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote: > >- Do you have atomic instructions. >- Do you have one CPU or multiple CPUs. Of course you are right. > > Let's assume you have a single CPU and no special atomic instructions. > >- Copy the trick used on ARM to implement atomic-compare-exchange > in the vsyscall page, without disabling interrupts. Modern ARM variants have "load-Link / Store-Conditional" instructions. NIOS does not have those and I don't suppose Microblaze has. > > The vsyscall trick is a good one, and works with/without MMU, and > with/without permission to disable interrupts in userspace. It's fast > too. I recommend reading the code. It's only a few instructions. > I'll do so. Does the "vsyscall trick" not force a trap and thus Kernel interaction ? Thanks ! -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
Re: [uClinux-dev] Shell exits while running a program.
> The vsyscall trick is a good one, and works with/without MMU, and > with/without permission to disable interrupts in userspace. Unfortunately I don't find something about the "vsyscall trick" in the Kernel sources not in the glibC sources. But I don't have found the glibC sources for ARM yet, nor other hints on doing atomic operation with the help of the vsyscall page (that is described as a memory area that all processes can access, so it seems atomic operations are required here, not provided). I'd be happy if you could give some more pointers. -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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > > The vsyscall trick is a good one, and works with/without MMU, and > > with/without permission to disable interrupts in userspace. > > Unfortunately I don't find something about the "vsyscall trick" in the > Kernel sources not in the glibC sources. Look in arch/arm/kernel/entry-armv.S for __kernel_cmpxchg, kuser_cmpxchg_fixup, and all the places where kuser_cmpxchg_fixup is called in that file. I haven't read the relevant glibc sources, but I have written code which uses __kernel_cmpxchg from my own application. > nor other hints on doing atomic operation > with the help of the vsyscall page (that is described as a memory area > that all processes can access, so it seems atomic operations are > required here, not provided). The vsyscall page is shared among all processes, but read only. (And sometimes per-CPU). Of course of you don't have an MMU or MPU then it can be written, but that's not meant to happen. kernel_cmpxchg accesses memory in your own process, that is, inside your own pthread_mutex_t structs, not in the vsyscall page. The point is that the code for kernel_cmpxchg is in the vsyscall page. That's part of the trick that makes it possible. -- 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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > > Let's assume you have a single CPU and no special atomic instructions. > > > >- Copy the trick used on ARM to implement atomic-compare-exchange > > in the vsyscall page, without disabling interrupts. > > Modern ARM variants have "load-Link / Store-Conditional" instructions. Only quite recent ARMs. Not the ones I'm working yet :-) > NIOS does not have those and I don't suppose Microblaze has. With one CPU they're not really needed. > > The vsyscall trick is a good one, and works with/without MMU, and > > with/without permission to disable interrupts in userspace. It's fast > > too. I recommend reading the code. It's only a few instructions. > > I'll do so. > > Does the "vsyscall trick" not force a trap and thus Kernel interaction ? No, no trap. Also, ignore the bits in arch/arm/kernel/entry-armv.S which disable the trick for noMMU. It's just because it needs to work at a relocated address and nobody's implemented that. See also kuser_cmpxchg_check (as opposed to .._fixup). That check doesn't work on noMMU in general because of the different address space layout. -- 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
Re: [uClinux-dev] Shell exits while running a program.
Don't know if your version has this but: (From a post dated 2004) The latest version of the microblaze core in EDK6.2 SP1 (microblaze_v2_10_a) has optional support for a new pair of instructions: msrset rd, IMM and msrclr rd, IMM this pair of instructions are basically an atomic test-and-set on the microblaze status register. We lobbied Xilinx to add these on the grounds of the code size reduction: mfsrd, rmsr andird, rd, ~2 mtsrmsr, rd becomes msrclrr0, ~2 to clear interrupts, and similarly for enable interrupts (and caches too). Also you no longer need a scratch register when doing these manipulations on the MSR. Even better (well, in fact by design!), the msrclr instruction maps directly onto the very common save_flags_cli() macro, that is sprinkled liberally throughout the kernel and drivers. On Thu, Aug 6, 2009 at 9:51 AM, Jamie Lokier wrote: > Michael Schnell wrote: > > > Let's assume you have a single CPU and no special atomic instructions. > > > > > >- Copy the trick used on ARM to implement atomic-compare-exchange > > > in the vsyscall page, without disabling interrupts. > > > > Modern ARM variants have "load-Link / Store-Conditional" instructions. > > Only quite recent ARMs. Not the ones I'm working yet :-) > > > NIOS does not have those and I don't suppose Microblaze has. > > With one CPU they're not really needed. > > > > The vsyscall trick is a good one, and works with/without MMU, and > > > with/without permission to disable interrupts in userspace. It's fast > > > too. I recommend reading the code. It's only a few instructions. > > > > I'll do so. > > > > Does the "vsyscall trick" not force a trap and thus Kernel interaction ? > > No, no trap. > > Also, ignore the bits in arch/arm/kernel/entry-armv.S which disable > the trick for noMMU. It's just because it needs to work at a > relocated address and nobody's implemented that. See also > kuser_cmpxchg_check (as opposed to .._fixup). That check doesn't work > on noMMU in general because of the different address space layout. > > -- 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 > ___ 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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote: > Look in arch/arm/kernel/entry-armv.S for __kernel_cmpxchg, > kuser_cmpxchg_fixup, and all the places where kuser_cmpxchg_fixup is > called in that file. > Here they say: /* * The only thing that can break atomicity in this cmpxchg * implementation is either an IRQ or a data abort exception * causing another process/thread to be scheduled in the middle * of the critical sequence. To prevent this, code is added to * the IRQ and data abort exception handlers to set the pc back * to the beginning of the critical section if it is found to be * within that critical section (see kuser_cmpxchg_fixup). */ So the "trick" involves modifying the basic interrupt handler code. This of course is a *nasty* trick. I'll take a look if this is viable for the NIOS architecture. Thanks for pointing me there, -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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: > this pair of instructions are basically an atomic test-and-set on the > microblaze status register. An atomic operation on some dedicated bits located in the "processor" rather than in memory. This is exactly what I intended to do for adding Futex to the NIOS2 arch. Adding such an instruction as a "custom instruction" to the NIOS2 Processor is quite easy and can be done by the customer when implementing his FPGA project. > We lobbied Xilinx to add these on the > grounds of the code size reduction: > > mfsrd, rmsr > andird, rd, ~2 > mtsrmsr, rd > > becomes > > msrclrr0, ~2 > > to clear interrupts, and similarly for enable interrupts (and caches > too). Also you no longer need a scratch register when doing these > manipulations on the MSR. Would disabling / enabling the interrupt be possible in user mode (especially when running MMU enabled "full" Linux ? -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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > Jamie Lokier wrote: > > Look in arch/arm/kernel/entry-armv.S for __kernel_cmpxchg, > > kuser_cmpxchg_fixup, and all the places where kuser_cmpxchg_fixup is > > called in that file. > > > > Here they say: > /* >* The only thing that can break atomicity in this cmpxchg >* implementation is either an IRQ or a data abort exception >* causing another process/thread to be scheduled in the middle >* of the critical sequence. To prevent this, code is added to >* the IRQ and data abort exception handlers to set the pc back >* to the beginning of the critical section if it is found to be >* within that critical section (see kuser_cmpxchg_fixup). >*/ > > So the "trick" involves modifying the basic interrupt handler code. > This of course is a *nasty* trick. Only the common entry or exit path. Nasty perhaps (I like it), but fast - good for thread primitives. It's a moderately common trick in tight code on microcontrollers, to move a check out of some critical fast path (especially copying and I/O loops) into the rarely executed interrupt handlers. It's also done in userspace, e.g. by signal handlers in some Java runtimes, again to move checks away from frequently executed fast paths in regular code. It's worthy of a Pattern name but I don't know if there is one (or an Anti-pattern if you prefer ;-) If you don't like that, you might not like other dirty tricks in the interrupt path like TIF_NEED_RESCHED and TIF_RESTORE_SIGMASK... but they do the job. :-) > I'll take a look if this is viable for the NIOS architecture. On noMMU, an alternative to using a vsyscall page is to put the cmpxchg routine in userspace (in Glibc/uclibc), and tell the kernel what addresses to check for, with a dedicated system call (just like set_thread_area has a dedicated system call). The kernel will store the address in per-task state. That will save a memory load on noMMU when calling the routine because it'll be a direct call instead of indirect. -- 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
Re: [uClinux-dev] Shell exits while running a program.
>>Would disabling / enabling the interrupt be possible in user mode >>(especially when running MMU enabled "full" Linux ? That would depend on the arch of the MCU - May or may not be enforceable by the kernel. What should be done is that a "mutex" object should do this for you (i.e patch the code in the kernel). I am amazed that the base design did not have atomic instructions. . On Thu, Aug 6, 2009 at 10:18 AM, Michael Schnell wrote: > Jim Donelson wrote: > > > this pair of instructions are basically an atomic test-and-set on the > > microblaze status register. > > An atomic operation on some dedicated bits located in the "processor" > rather than in memory. This is exactly what I intended to do for adding > Futex to the NIOS2 arch. Adding such an instruction as a "custom > instruction" to the NIOS2 Processor is quite easy and can be done by the > customer when implementing his FPGA project. > > > We lobbied Xilinx to add these on the > > grounds of the code size reduction: > > > > mfsrd, rmsr > > andird, rd, ~2 > > mtsrmsr, rd > > > > becomes > > > > msrclrr0, ~2 > > > > to clear interrupts, and similarly for enable interrupts (and caches > > too). Also you no longer need a scratch register when doing these > > manipulations on the MSR. > > Would disabling / enabling the interrupt be possible in user mode > (especially when running MMU enabled "full" Linux ? > > -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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > Jim Donelson wrote: > > > this pair of instructions are basically an atomic test-and-set on the > > microblaze status register. > > An atomic operation on some dedicated bits located in the "processor" > rather than in memory. This is exactly what I intended to do for adding > Futex to the NIOS2 arch. Adding such an instruction as a "custom > instruction" to the NIOS2 Processor is quite easy and can be done by the > customer when implementing his FPGA project. 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. 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. > > We lobbied Xilinx to add these on the > > grounds of the code size reduction: > > > > mfsrd, rmsr > > andird, rd, ~2 > > mtsrmsr, rd > > > > becomes > > > > msrclrr0, ~2 > > > > to clear interrupts, and similarly for enable interrupts (and caches > > too). Also you no longer need a scratch register when doing these > > manipulations on the MSR. > > Would disabling / enabling the interrupt be possible in user mode > (especially when running MMU enabled "full" Linux ? The ability to disable interrupts breaks process protection - any process can lock up the system - so it's usually prevented when you have an MMU. Without an MMU or MPU you can break the system in so many other ways that it doesn't matter so much :-) However, another trick would be let userspace disable interrupts for a maximum of N instructions (for some small N). That would maintain process protection. Note that interrupt-disabling can be a bit slow on some CPUs (it may have to flush the pipeline to take effect immediately), which is another reason to look at other methods. -- 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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: >>>Would disabling / enabling the interrupt be possible in user mode >>>(especially when running MMU enabled "full" Linux ? > >That would depend on the arch of the MCU - May or may not be >enforceable by the kernel. >What should be done is that a "mutex" object should do this for you >(i.e patch the code in the kernel). The whole point of futex is to _avoid_ system calls when possible, for performance. System calls aren't super slow, but locking primitives are called very often in some code. So good performance means finding a way to simulate atomic memory updates in userspace without a user/kernel transition. If you can't find any other way, then do that, but it's best avoided. >I am amazed that the base design did not have atomic instructions. Well, they aren't free in terms of FPGA resources, they'd make the attainable clock speed a bit slower, and they aren't necessary if you have one CPU. But I agree they would have made sense an an optional feature. I wonder if load-locked/store-conditional is covered by patents... -- 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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote: > 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. And if you can do that, you can probably make the custom CPU clear the flag _automatically_ on return-from-interrupt instructions :-) -- 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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote: ... Interesting stuff ! > On noMMU, an alternative to using a vsyscall page is to put the > cmpxchg routine in userspace (in Glibc/uclibc), and tell the kernel > what addresses to check for, with a dedicated system call (just like > set_thread_area has a dedicated system call). The kernel will store > the address in per-task state. AFAIK, with NIOS2, on non-MMU designs, you can deactivate/activate the Interrupt in User space, so no problem here anyway. But I am planing for an MMU-enabled design. -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
Re: [uClinux-dev] Shell exits while running a program.
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
Re: [uClinux-dev] Shell exits while running a program.
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. > > 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.) -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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote:
>
> And if you can do that, you can probably make the custom CPU clear the
> flag _automatically_ on return-from-interrupt instructions :-)
Unfortunately the power of custom instructions is not that great with
NIOS2. With a MICO32 CPU that you implement in native HDL code and thus
can be modified in any way you want such nice things would be possible
(especially accessing memory from an additionally implemented
instruction), but the NIOS is closed source and hand-optimized by Altera
for the FPGA architecture (and thus I *hope* it is fast).
That is why custom instructions are restricted to resources offered by
the NIOS2 design (the two "read" registers given in the instruction.
I.e. the single "write" registers given in the instruction, bus
interface ("behind" the cache).
-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
Re: [uClinux-dev] Shell exits while running a program.
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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote: > Clever. That's going in my algorithms file. Thanks for the KUDOs :) > > 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. That is why I intend to do multiple Hardware based Futexes and map them to the real Futexes (easiest way: use bits 2, 3, ... of the address if the memory based Futex as an "address" of the hardware Futex. I suppose this will relax the stress on a certain hardware Futex. > Yes, other variations on 'nasty' hacks in the ISR entry/exit path include: ... Thanks ! I'll be considering these. -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
Re: [uClinux-dev] Shell exits while running a program.
>- 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. > ... and similar tricks: The ISR needs to know if the value already had been modified (i.e stored) or not. So it needs to check if the PC was before or after the store instruction and have the user space function either redo the critical section or just proceed. -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
Re: [uClinux-dev] Shell exits while running a program.
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 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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: >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. Fine in theory. ARM has an instruction like that, called SWP, and I've written mutex code with it. It turns out to be difficult to use efficiently from userspace. Most example locking code makes spinlocks with it. That's easy, but spinlocks are extremely inefficient when preempted inside a critical section. And you can't disable preemption in userspace code. The problem is process A has the lock and is preempted, then process B tries to get the lock and finds it doesn't have it. What does process B do? If it spins, that will waste CPU for a long time. If it calls sched_yield(), process B gets an unfairly small share of the CPU. It can't call FUTEX_WAIT, unless it has a way to signal process A when to call FUTEX_WAKE... In fact you can write an efficient mutex using atomic exchange and futex, but it's quite tricky and it's not any of the usual, documented futex algorithms. The algorithms generally used with futex in NPTL, for things like mutexes, rwlocks and condition varibles, do not work with atomic exchange; they require atomic compare-exchange. You can build the other algorithms on top of a basic mutex, as Michael is doing, but you have to be careful to ensure performance doesn't plummet when preempted. The simple spinlock algorithms aren't suitable. -- 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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: > 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. True with a Mutex, not true with a Futex. Here you need a second bit in user-space that tells the releaser that it is to wake up a sleeping waiter. Otherwise, any release would need a system call. Seemingly the best instruction to handle these bits is "atomic compare and exchange" (e.g. provided by the X86 CPU). OTOH with a load-store-architecture CPU it's not that simple to add a memory read-modify write instruction to the ISA, while it's no big problem to have such an instruction do with the data whatever is appropriate. -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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > disables the global interrupt for the next three > instructions. True for the NIOS, that does not use "Flags" - but register compares - for conditional jumps, with an architecture that uses flags, I suppose you need a lock for four instructions. -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
Re: [uClinux-dev] Shell exits while running a program.
I now have a Futex testing program up and running. It performs three tests on different kinds of Mutex implementation for threads all running the same code: Test 1: only one thread, many Mutex calls protecting a small critical section Test 2: multiple threads many Mutex calls protecting a small critical section Test 3: multiple threads, only a few Mutex calls protecting a critical section that contains a long lasting loop This is tested with these Futex implementations: 1) Dummy: Of course does not work, but used as reference for estimating the performance of the different Mutex implementations. 2) A simple protection done with atomic operations and having the thread do a short sleep if it can't get the lock. (Does not work on the NIOS, as there are no atomic operations) 3) using the pthread_mutex calls of the pthread library (which does Futex with X86 vs. some system calls with the NIOS2) 4) a Futex implementation based on the paper "Futexes Are Tricky" by Ulrich Depper, code variant "Take 2" (not yet done for NIOS) 5) a Futex implementation based on the paper "Futexes Are Tricky" by Ulrich Depper, code variant "Take 3" (not yet done for NIOS) 6) using Linux System V semaphore. (On the PC, some 10 times slower than anything else, on NIOS performing very similar to pthread_mutex) If anybody wants to try it I can post it somewhere. -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
Re: [uClinux-dev] Shell exits while running a program.
I forgot to mention, that the test calculates the overhead imposed by the Mutex code in terms of "Wall clock" and "usage time" seconds. -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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > I now have a Futex testing program up and running. You may wish to look at Glibc's pthread tests too. They did a lot of testing to make sure the NPTL futex usage is correct with all kind of primitives, not just thread mutexes, but condition variables, rwlocks, and inter-process versions too. They also did a lot of benchmarks, which is why sys_futex was changed from an elegant simple thing to what it is today. Also, you may wish to look at the robust real-time mutexes with priority inheritance (RT and PI are keywords), which works alongside RT kernels. -- 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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > Michael Schnell wrote: > > disables the global interrupt for the next three > > instructions. > > True for the NIOS, that does not use "Flags" - but register compares - > for conditional jumps, with an architecture that uses flags, I suppose > you need a lock for four instructions. That sounds right. Three instructions is also enough for atomic-add, atomic-sub, atomic-and etc. in addition to compare-exchange. Although compare-exchange is universal, sometimes it takes more time busy spinning compared with an atomic arithmetic or logical operation, when under high contention with multiple CPUs. Four instructions is enough for a versatile logic sequence: LOAD [addr], reg AND #xxx, reg XOR #yyy, reg STORE reg, [addr] -- 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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote: > Although compare-exchange is universal, sometimes it takes more time > busy spinning compared with an atomic arithmetic or logical operation, > when under high contention with multiple CPUs. I'm being a bit stupid here. The interrupt-disabling method doesn't work with multiple CPUs anyway. compare-exchange spinning is reduced, probably to virtually zero, when there's only one CPU and you're not getting interrupts at an extreme rate. -- 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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > Jim Donelson wrote: > > 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. > > True with a Mutex, not true with a Futex. Here you need a second bit in > user-space that tells the releaser that it is to wake up a sleeping > waiter. Otherwise, any release would need a system call. Indeed. A atomic-swap instruction provides enough bits, but it's hard to get the algorithm right. > Seemingly the best instruction to handle these bits is "atomic compare > and exchange" (e.g. provided by the X86 CPU). It's actually not the best, because when it returns "did not match" you have to loop and try again. The amount of looping depends on contention level. Ideal would be an atomic-do-what-I-need-for-my-algorithm operation. However, atomic-compare-exchange can be used for everything, so it's a useful instruction if you have to pick one. -- 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
Re: [uClinux-dev] Shell exits while running a program.
>It's actually not the best, because when it returns "did not match" >you have to loop and try again. Not sure what else you would do? The purpose of a spin lock is to avoid a more expensive kernel call if the mutex is released quickly (or not taken at all). Presumably you enter the kernel after n tries and sleep so that you are not using up quanta while spinning. >The amount of looping depends on >contention level. The real secret is to reduce the time spent holding the mutex in general. As for priority inversion (where a lower priority task gets to execute because is it holding a mutex that a higher priority thread is waiting on) that should be addressed in the kernel. The lower priority thread should get temporary priority elevation. On Tue, Aug 11, 2009 at 9:34 AM, Jamie Lokier wrote: > Michael Schnell wrote: > > Jim Donelson wrote: > > > 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. > > > > True with a Mutex, not true with a Futex. Here you need a second bit in > > user-space that tells the releaser that it is to wake up a sleeping > > waiter. Otherwise, any release would need a system call. > > Indeed. A atomic-swap instruction provides enough bits, but it's hard > to get the algorithm right. > > > Seemingly the best instruction to handle these bits is "atomic compare > > and exchange" (e.g. provided by the X86 CPU). > > It's actually not the best, because when it returns "did not match" > you have to loop and try again. The amount of looping depends on > contention level. Ideal would be an > atomic-do-what-I-need-for-my-algorithm operation. However, > atomic-compare-exchange can be used for everything, so it's a useful > instruction if you have to pick one. > > -- 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 > ___ 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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote:
> >It's actually not the best, because when it returns "did not match"
> >you have to loop and try again.
>
> Not sure what else you would do? The purpose of a spin lock is to
> avoid a more expensive kernel call
It's not a spinlock.
This loop is for a different reason. You can tell it's different
because it spins when *unlocking* too; a spinlock never does that.
The "did not match" case for compare-exchange is to simulate an atomic
operation like this example:
int atomic_dec_test(unsigned *mem)
{
do {
old = *mem;
new = old+1;
} while (!compare_exchange(mem, old, new));
return (new != 0);
}
void mutex_unlock(unsigned *mem)
{
if (atomic_dec_test(mem))
futex(FUTEX_WAKE, mem);
}
> > The amount of looping depends on contention level.
>
> The real secret is to reduce the time spent holding the mutex in general.
Think about the code above. The amount of looping in
atomic_dec_test(), above, is not reduced by reducing the time spent
holding the mutex.
If you hold the mutex for shorter times in more places (moving the
mutex from large regions to small ones), paradoxically it will
*increase* the average amount of looping in atomic_dec_test() and the
other atomic ops. Usually not by enough to care, but it depends on
the program.
That why compare-exchange (and load-locked/store-conditional CPU
instructions), though universally usable, doesn't have the same
performance characteristics as atomic read-modify-writed ops. Though,
atomic ops are sometimes implemented as lock-locked/store-conditional
in the chip anyway.. it's a subtle area.
> The purpose of a spin lock is to avoid a more expensive kernel call
> if the mutex is released quickly (or not taken at all). Presumably
> you enter the kernel after n tries and sleep so that you are not
> using up quanta while spinning.
That doesn't work with a single processor. While you are spinning,
it's impossible for the other thread to release the mutex until you
are preempted, so potential benefit from spinning is marginal and
often outweight by the benefit of not spinning.
> As for priority inversion (where a lower priority task gets to execute
> because is it holding a mutex that a higher priority thread is waiting
> on) that should be addressed in the kernel. The lower priority thread
> should get temporary priority elevation.
Yes, that's what the robust PI mutexes implemention does.
It uses futexes in userspace to avoid entering the kernel just like
the standard futex algorithms, but priority inheritance if it enters
the kernel, and cleverly if a thread or process crashes, the mutex is
safely recoverable too.
-- 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
Re: [uClinux-dev] Shell exits while running a program.
On Tue, Aug 11, 2009 at 12:27 PM, Jamie Lokier wrote:
> Jim Donelson wrote:
> > >It's actually not the best, because when it returns "did not match"
> > >you have to loop and try again.
> >
> > Not sure what else you would do? The purpose of a spin lock is to
> > avoid a more expensive kernel call
>
> It's not a spinlock.
>
> This loop is for a different reason. You can tell it's different
> because it spins when *unlocking* too; a spinlock never does that.
>
> The "did not match" case for compare-exchange is to simulate an atomic
> operation like this example:
>
>int atomic_dec_test(unsigned *mem)
>{
>do {
>old = *mem;
>new = old+1;
>} while (!compare_exchange(mem, old, new));
>
>return (new != 0);
>}
>
>void mutex_unlock(unsigned *mem)
>{
>if (atomic_dec_test(mem))
> futex(FUTEX_WAKE, mem);
> }
>
I'd like to see the code for compare_exchange and the lock function.
>
> > > The amount of looping depends on contention level.
> >
> > The real secret is to reduce the time spent holding the mutex in general.
>
> Think about the code above. The amount of looping in
> atomic_dec_test(), above, is not reduced by reducing the time spent
> holding the mutex.
>
> If you hold the mutex for shorter times in more places (moving the
> mutex from large regions to small ones), paradoxically it will
> *increase* the average amount of looping in atomic_dec_test() and the
> other atomic ops. Usually not by enough to care, but it depends on
> the program.
>
> That why compare-exchange (and load-locked/store-conditional CPU
> instructions), though universally usable, doesn't have the same
> performance characteristics as atomic read-modify-writed ops. Though,
> atomic ops are sometimes implemented as lock-locked/store-conditional
> in the chip anyway.. it's a subtle area.
>
> > The purpose of a spin lock is to avoid a more expensive kernel call
> > if the mutex is released quickly (or not taken at all). Presumably
> > you enter the kernel after n tries and sleep so that you are not
> > using up quanta while spinning.
>
> That doesn't work with a single processor. While you are spinning,
> it's impossible for the other thread to release the mutex until you
> are preempted, so potential benefit from spinning is marginal and
> often outweight by the benefit of not spinning.
>
Of course it does - sleeping on a sp means "preempt me now".
>
> > As for priority inversion (where a lower priority task gets to execute
> > because is it holding a mutex that a higher priority thread is waiting
> > on) that should be addressed in the kernel. The lower priority thread
> > should get temporary priority elevation.
>
> Yes, that's what the robust PI mutexes implemention does.
>
> It uses futexes in userspace to avoid entering the kernel just like
> the standard futex algorithms, but priority inheritance if it enters
> the kernel, and cleverly if a thread or process crashes, the mutex is
> safely recoverable too.
>
> -- 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
>
___
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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: > I'd like to see the code for compare_exchange and the lock function. compare_exchange is a single architecture-specific instruction; that's what we're discussing. Lock functions are described in Ulrich Drepper's futex paper. >> The purpose of a spin lock is to avoid a more expensive kernel call >> if the mutex is released quickly (or not taken at all). Presumably >> you enter the kernel after n tries and sleep so that you are not >> using up quanta while spinning. > > That doesn't work with a single processor. While you are spinning, > it's impossible for the other thread to release the mutex until you > are preempted, so potential benefit from spinning is marginal and > often outweight by the benefit of not spinning. > >Of course it does - sleeping on a sp means "preempt me now". Yes, but *spinning* on a spinlock does not. You propose spinning n times before sleeping. The mutex will only be released during spin time if you are randomly preempted during that short time. -- 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
Re: [uClinux-dev] Shell exits while running a program.
On Tue, Aug 11, 2009 at 4:58 PM, Jamie Lokier wrote: > Jim Donelson wrote: > > I'd like to see the code for compare_exchange and the lock function. > > compare_exchange is a single architecture-specific instruction; that's > what we're discussing. Lock functions are described in Ulrich > Drepper's futex paper. In the context of Drepper's paper, you code looks bugged. You add, not subtract, and you never set mem to 0. > > >> The purpose of a spin lock is to avoid a more expensive kernel call > >> if the mutex is released quickly (or not taken at all). Presumably > >> you enter the kernel after n tries and sleep so that you are not > >> using up quanta while spinning. > > > > That doesn't work with a single processor. While you are spinning, > > it's impossible for the other thread to release the mutex until you > > are preempted, so potential benefit from spinning is marginal and > > often outweight by the benefit of not spinning. > > > >Of course it does - sleeping on a sp means "preempt me now". > > Yes, but *spinning* on a spinlock does not. You propose spinning n > times before sleeping. The mutex will only be released during spin > time if you are randomly preempted during that short time. Obviously, in the case of an SP, n = 1. > > > -- 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 > ___ 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
Re: [uClinux-dev] Shell exits while running a program.
>> Seemingly the best instruction to handle these bits is "atomic compare >> and exchange" (e.g. provided by the X86 CPU). > > It's actually not the best, because when it returns "did not match" > you have to loop and try again. The supposedly "best" user space implementation for the X86 I found (in "Futexes are Tricky") uses both "atomic_compare_and_exchange" and "atomic_exchange" for the lock part and "atomic_dec" for the unlock part. -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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: > I'd like to see the code for compare_exchange and the lock function. Best Read: "Futexes Are Tricky" by Ulrich Drepper, Redhat. -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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: > Of course it does - sleeping on a sp means "preempt me now". Thus the spinning loop needs to do a sleep system call. This means the process gives up it's current time slice. St least with a non-realtime scheduling paradigm, this makes the wall-clock speed of the thread very slow. I did a testing program (see another message in this thread) that times several different user space Mutex algorithms. A simple one of them is this kind of spinnlock. Of course the said behavior is shown. -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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote: > > compare_exchange is a single architecture-specific instruction; that's > what we're discussing. Not really. The OP is working with Microblaze, I am working with NIOS2. Both archs do not have any provision for atomic memory modification at all, so we need to implement it by some pure software tricks (i.e. special provisions in the general ISR entry code) or by implementing a dedicated custom instruction. -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
Re: [uClinux-dev] Shell exits while running a program.
Thanks for the pointers ! -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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > Jamie Lokier wrote: > > > > compare_exchange is a single architecture-specific instruction; that's > > what we're discussing. > > Not really. The OP is working with Microblaze, I am working with NIOS2. > Both archs do not have any provision for atomic memory modification at > all, so we need to implement it by some pure software tricks (i.e. > special provisions in the general ISR entry code) or by implementing a > dedicated custom instruction. Sorry, the topic wandered a bit, and *I* was talking about the relative merits of atomic compare-exchange versus atomic read-modify-write instruction... :-) The general principle also applies to a custom instruction operating on special registers - avoid spinning to implement the 'atomic' part, and don't confuse that with spinning on a lock. But it's not that significant in the scheme of things. -- 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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: > >> Seemingly the best instruction to handle these bits is "atomic compare > >> and exchange" (e.g. provided by the X86 CPU). > > > > It's actually not the best, because when it returns "did not match" > > you have to loop and try again. > > The supposedly "best" user space implementation for the X86 I found (in > "Futexes are Tricky") uses both "atomic_compare_and_exchange" and > "atomic_exchange" for the lock part and "atomic_dec" for the unlock part. That's right. It's possible to use atomic_compare_and_exchange for unlock; it's correct. But you get that extra bit of spinning with SMP, so atomic_dec is better. -- 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
Re: [uClinux-dev] Shell exits while running a program.
I wonder why (on an SP machine) you don't just disable interrupts for a few instructions and give yourself an atomic dec? On Wed, Aug 12, 2009 at 9:30 AM, Jamie Lokier wrote: > Michael Schnell wrote: > > >> Seemingly the best instruction to handle these bits is "atomic compare > > >> and exchange" (e.g. provided by the X86 CPU). > > > > > > It's actually not the best, because when it returns "did not match" > > > you have to loop and try again. > > > > The supposedly "best" user space implementation for the X86 I found (in > > "Futexes are Tricky") uses both "atomic_compare_and_exchange" and > > "atomic_exchange" for the lock part and "atomic_dec" for the unlock part. > > That's right. It's possible to use atomic_compare_and_exchange for > unlock; it's correct. But you get that extra bit of spinning with SMP, > so atomic_dec is better. > > -- 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 > ___ 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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: >I wonder why (on an SP machine) you don't just disable interrupts for >a few instructions and give yourself an atomic dec? Yes, that's fine. However, it's not secure to allow userspace to disable interrupts(*), so we've talked about a custom instruction which lets userspace disable interrupts for a maximum of 3/4 instructions, then the hardware forces them on again. (*) with an MMU; without an MMU there's no security anyway so it doesn't matter as much. Personally I think the ARM method is nicest because it doesn't need any special hardware, but time-limited interrupt disabling may be a little bit faster, or slower, depending on the architecture. -- 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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote:
> That's right. It's possible to use atomic_compare_and_exchange for
> unlock; it's correct. But you get that extra bit of spinning with SMP,
> so atomic_dec is better.
In fact I don't see why Ulrich did the unlock code like this:
if (atomic_dec(val) != 1 ) {
val = 0;
futex_wake(&val, 1);
};
My current implementation is
c = atomic_xchg(val, 0) {
if (c=2) { // we own the lock, so
// val can be either of 1 or 2
futex_wake(&val, 1);
};
It does work fine in my tests on a dual core.
What do you think ?
-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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: > > I wonder why (on an SP machine) you don't just disable interrupts for a > few instructions and give yourself an atomic dec? With many archs it's not possible to disable/enable interrupts in user-space. -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
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote:
> Jamie Lokier wrote:
> > That's right. It's possible to use atomic_compare_and_exchange for
> > unlock; it's correct. But you get that extra bit of spinning with SMP,
> > so atomic_dec is better.
>
> In fact I don't see why Ulrich did the unlock code like this:
>
> if (atomic_dec(val) != 1 ) {
> val = 0;
> futex_wake(&val, 1);
> };
>
>
>
> My current implementation is
>
> c = atomic_xchg(val, 0) {
> if (c=2) { // we own the lock, so
>// val can be either of 1 or 2
> futex_wake(&val, 1);
> };
Second implementation:
Thread 1 Thread 2 Thread 3
[owns the lock] [running] [waiting]
c = atomic_xchg(val, 0);
[c == 2]
if (compare_swap(val, 0, 1))
return;
[owns the lock]
futex_wake(&val, 1);
[wakes Thread 3] [woken by Thread 1]
if (compare_swap(val,
0, 1))
[no]
compare_sawp(val, 1,
2))
[waiting]
In Ulrich's version Thread 2 sleeps and Thread 3 runs, which is about
the same cost. Keeping Thread 2 running is probably better for
average throughput.
But Ulrich's version is fairer, and does not allow starvation.
In your version Thread 3 can be starved by threads which are already
running, and that can happen repeatedly so it never runs. In Ulrich's
version, all threads are guaranteed to run because there's a FIFO
queue on the futex, modified only by desired scheduling policies.
-- 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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote: > In Ulrich's > version, all threads are guaranteed to run because there's a FIFO > queue on the futex, modified only by desired scheduling policies. Great argument ! I'll convert to Ulrich's version. Thanks a lot ! -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
Re: [uClinux-dev] Shell exits while running a program.
On Wed, Aug 12, 2009 at 10:41 AM, Michael Schnell wrote: > Jim Donelson wrote: > > > > I wonder why (on an SP machine) you don't just disable interrupts for a > > few instructions and give yourself an atomic dec? > > > With many archs it's not possible to disable/enable interrupts in > user-space. > But, then if you have an MMU, you have atomic instructions. > > -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
Re: [uClinux-dev] Shell exits while running a program.
On Thursday 06 August 2009 11:01:01 Jamie Lokier wrote: > Michael Schnell wrote: > > I'll take a look if this is viable for the NIOS architecture. > > On noMMU, an alternative to using a vsyscall page is to put the > cmpxchg routine in userspace (in Glibc/uclibc), and tell the kernel > what addresses to check for, with a dedicated system call (just like > set_thread_area has a dedicated system call). The kernel will store > the address in per-task state. > > That will save a memory load on noMMU when calling the routine > because it'll be a direct call instead of indirect. the Blackfin port does this with a "fixed code" region where we've reserved the lowest 4k of memory: - first 1k is to catch NULL pointers - next ~1k is user-space atomic code (initialized by kernel at boot) so when userspace wants to do atomic functions (since the hardware doesnt support it), it calls the functions hardcoded in this region. when the kernel goes to return to userspace, it checks the PC isnt in this region. if it is, it will finish the atomic operation for userspace and update the PC. -mike signature.asc Description: This is a digitally signed message part. ___ 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
Re: [uClinux-dev] Shell exits while running a program.
On Wednesday 12 August 2009 12:36:02 Jim Donelson wrote: > On Wed, Aug 12, 2009 at 10:41 AM, Michael Schnell wrote: > > Jim Donelson wrote: > > > I wonder why (on an SP machine) you don't just disable interrupts for a > > > few instructions and give yourself an atomic dec? > > > > With many archs it's not possible to disable/enable interrupts in > > user-space. > > But, then if you have an MMU, you have atomic instructions. assuming you mean hardware atomic instructions, the answer is "not really". -mike signature.asc Description: This is a digitally signed message part. ___ 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
Re: [uClinux-dev] Shell exits while running a program.
On Wednesday 12 August 2009 10:36:02 Jamie Lokier wrote: > Jim Donelson wrote: > >I wonder why (on an SP machine) you don't just disable interrupts for > >a few instructions and give yourself an atomic dec? > > Yes, that's fine. > > However, it's not secure to allow userspace to disable interrupts(*), > so we've talked about a custom instruction which lets userspace > disable interrupts for a maximum of 3/4 instructions, then the > hardware forces them on again. > > (*) with an MMU; without an MMU there's no security anyway so it > doesn't matter as much. s/without an MMU/without an MMU or MPU/ ;) -mike signature.asc Description: This is a digitally signed message part. ___ 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
Re: [uClinux-dev] Shell exits while running a program.
Mike Frysinger wrote: > - next ~1k is user-space atomic code (initialized by kernel at boot) > > so when userspace wants to do atomic functions (since the hardware doesnt > support it), it calls the functions hardcoded in this region. when the > kernel > goes to return to userspace, it checks the PC isnt in this region. if it is, > it will finish the atomic operation for userspace and update the PC. How exactly is this done ? I suppose it imposes some additional overhead to each interrupt, as on entry or exit there is some code that checks whether the PC had been in that region (this is what you say). If it is I suppose some "interesting" code is necessary to find out if the should-be atomic code sequence already is finished (with a write memory instruction) or if it is not yet finished and according to that act appropriately by - only in case of not finished - setting the return PC to the point of restarting the atomic code sequence. Moreover each atomic_xxx() function needs some additional overhead as it can't be inlined but needs a far call (and thus additional cache usage) to the special region. Are some atomic functions predefined in the said region or do the user space programs need to create them (in fact I suppose the region is write protected, if that is possible with the chip ??? ) ? Do you thinks this is an appropriate addition to the NIOS2 distribution ? (My other idea is to do a hardware "custom instruction" that creates a dedicated Futex that can be used to protect atomic code sequences.) Thanks for jumping in here, -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
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: > With many archs it's not possible to disable/enable interrupts in > user-space. > > > But, then if you have an MMU, you have atomic instructions. Why do you think so ? Maybe with ARM, all of them that have an MMU do have the "load locked" instruction. (I'm not very fluent with ARM.) But this seems to be not true for NIOS2, Microblaze and Blackfin. -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
Re: [uClinux-dev] Shell exits while running a program.
On Thursday 13 August 2009 03:22:43 Michael Schnell wrote: > Mike Frysinger wrote: > > - next ~1k is user-space atomic code (initialized by kernel at boot) > > > > so when userspace wants to do atomic functions (since the hardware doesnt > > support it), it calls the functions hardcoded in this region. when the > > kernel goes to return to userspace, it checks the PC isnt in this region. > > if it is, it will finish the atomic operation for userspace and update > > the PC. > > How exactly is this done ? > > I suppose it imposes some additional overhead to each interrupt, as on > entry or exit there is some code that checks whether the PC had been in > that region (this is what you say). the overhead is trivial and occurs just before resuming userspace. if the userspace PC is inside of the fixed atomic section range, then we finish the function execution in kernel space and update the PC. so in the most common case (userspace is not in the atomic section), the overhead is two compares (and related branching). in the uncommon case, the overhead is unavoidable. in much older versions of the Blackfin port, we had created a dedicated cmpxchg syscall for userspace to use, but we found the performance of that was incredibly worse compared to what we have now. arch/blackfin/... .../mach-common/entry.S - schedule_and_signal_from_int calls finish_atomic_sections .../kernel/process.c - finish_atomic_sections takes care of register munging .../kernel/fixed_code.S - this is the pure assembly that is relocated at kernel boot time > If it is I suppose some "interesting" code is necessary to find out if > the should-be atomic code sequence already is finished (with a write > memory instruction) or if it is not yet finished and according to that > act appropriately by - only in case of not finished - setting the return > PC to the point of restarting the atomic code sequence. > > Moreover each atomic_xxx() function needs some additional overhead as it > can't be inlined but needs a far call (and thus additional cache usage) > to the special region. > > Are some atomic functions predefined in the said region or do the user > space programs need to create them (in fact I suppose the region is > write protected, if that is possible with the chip ??? ) ? > > Do you thinks this is an appropriate addition to the NIOS2 distribution > ? (My other idea is to do a hardware "custom instruction" that creates a > dedicated Futex that can be used to protect atomic code sequences.) i'm not entirely sure what you're talking about here. the fixed code we have is for user space only and is not used directly by kernel space at all. the atomic functions are all trivial and impotent, so doing the register/memory munging directly and setting the PC to the end of the relevant function is easy to do. -mike signature.asc Description: This is a digitally signed message part. ___ 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
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote: > > > Thread 1 Thread 2 Thread 3 > > > [owns the lock] [running] [waiting] > > c = atomic_xchg(val, 0); > [c == 2] > if (compare_swap(val, 0, 1)) > return; > [owns the lock] > futex_wake(&val, 1); > [wakes Thread 3] [woken by Thread 1] > if > (compare_swap(val, 0, 1)) > [no] > compare_sawp(val, 1, > 2)) > [waiting] > Hmmm. After some more thinking, I don't see your point. Both implementation set the val to 0 unconditionally. Ulrich's code does this in two steps (if val was 2), but they follow immediately one after the other (specifically before waking the sleeping Thread 3). So the only difference that can arise is when Thread 2 (running) tries to lock the FUTEX exactly at the point in time when Thread 1 is right between the two steps. This is only two or three ASM instructions and thus extremely unlikely (even in an SMP situation). So I don't think there is any noticeable difference between the two implementations (unless one in fact is wrong for some reason I don't see yet.) -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
Re: [uClinux-dev] Shell exits while running a program.
Jamie, BTW. I am going to open a new thread here on implementing the Futex. I'd be happy if you could join. -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
Re: [uClinux-dev] Shell exits while running a program.
Mike Frysinger wrote: > arch/blackfin/... > .../mach-common/entry.S > - schedule_and_signal_from_int calls finish_atomic_sections > .../kernel/process.c > - finish_atomic_sections takes care of register munging > .../kernel/fixed_code.S > - this is the pure assembly that is relocated at kernel boot time > I'll take a look. > > i'm not entirely sure what you're talking about here. the fixed code we have > is for user space only and is not used directly by kernel space at all. That is my intention right now, too. > the > atomic functions are all trivial and impotent, so doing the register/memory > munging directly and setting the PC to the end of the relevant function is > easy to do. Sounds good. Using a hardware Futex with a NIOS2 custom instruction would be just another option that might or might not be advantageous, but of course not possible with Blackfin. -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
