Sebastian Kuzminsky wrote: > Sebastian Kuzminsky wrote: >> I could add a "threadsafe" flag to the board driver struct, which gets >> set by the board driver if the board I/O hardware is thread safe (PCI), >> and cleared if it's not (EPP). The high-level hostmot2 driver would >> examine this and only export the "full" read()/write() functions if the >> board driver is not thread safe. If the board driver *is* thread safe, >> the hostmot2 driver would in addition export gpio_read()/gpio_write(). > > If RTAI supported mutexes and thread-blocking, then fast gpio access > could be easily done even on the EPP boards. Instead of low-level > drivers exporting a "threadsafe" flag, the high-level hostmot2 driver > would create a mutex for each board, to make sure at most one RTAI > thread was executing in the low-level driver's read()/write() code at a > time. If another thread wanted to access the board, it would try to > lock the mutex and block until the first user was done. > No no no... that way lies priority inversion (http://en.wikipedia.org/wiki/Priority_inversion) and locked up computers.
If the servo thread happens to be accessing the board when the base thread starts, and the base thread wants to access the board, what happens? The base thread can't busy-wait - as long as it is running, the servo thread will never run, so it will never release the mutex. It can't just yield the CPU to the servo thread - that thread is a lower priority for a reason. Who knows how long it will keep the mutex, and how many other base thread interrupts might arrive in the meantime. This is a well known problem in task scheduling. There are some techniques, such as priority inheritance (http://en.wikipedia.org/wiki/Priority_inheritance), but none of them are guaranteed, and all of them are complex. If a lower priority thread holds a mutex, the only thing a higher priority thread can do is simply skip accessing the device, and hope that by the next time the thread runs, the mutex will have been freed. Of course, that risks completely missing a step pulse or encoder count. The simple fact is that the EPP bus is NOT shareable between realtime threads. That is only one of the reasons why (in my humble opinion) the PCI based 5i2x family is so much better than the EPP based 7i43 family. HAL (and EMC2) uses Rate Monotonic Scheduling (http://en.wikipedia.org/wiki/Rate_Monotonic_Scheduling) which is the simplest way to guarantee meeting realtime schedules and avoid deadlocks. However, you simply _cannot_ share a resource between threads. Changing the scheduling/priority algorithms is not something to be done lightly. I think it is perfectly reasonable for those who are using the EPP bus to have to live with GPIO accesses in the servo thread only. > It looks like rtai has semaphores but doesnt support blocking in the > kernel (no run queues). Maybe something like spinlocks could be built > around the non-blocking semaphore calls. > > Any comments on this? Anyone know RTAI? I really don't want to go there. We are talking about one use case, which everyone admits is not extremely common, and we've already discussed several possible workarounds that don't involve hacking the core realtime code. Regards, John Kasunich ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
