On 06/23/2010 05:35 PM, Daniël Mantione wrote: > > It's a non-issue. If you set a thread realtime you know what you are > doing and can take care you give up the CPU when feasible, or you > simply don't enter mutuxes shared with non-realtime threads.
I don't agree. If the RTL provides a method, it should be working and not unavoidably create a dead lock, even if a thread is set to a realtime priority. Moreover Thread Synchronization using FUTEX (via TCriticalSection) (implementing this directly in the RTL instead of using libc is what is being discussed right now here) is especially useful in a "realtime" system, as it improves the performance of the threaded application. Moreover the current implementation is not optimal at all even in a system with time-slices. If there is no other way with this arch but an active spinning lock, the blocked thread should at least give up it's current time slice before retrying to get the lock, so that the blocking thread can work and release the lock. otherwise (in a single CPU system) the resting part of the time slice is deterministically wasted. AFAIK calling "sleep(0)" would give up the time slice. -Michael _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
