Michael Schnell schrieb: > 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.
Tell this the writers of the cpu architecture manuals. > 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. Well, yes, you shouldn't simply use locked operations in a single cpu environment, your application should provide different algorithms for single and multi cpu/threaded environments if the application really contains speed critical code requiring locking. This is why FPC uses inclocked/declocked for fast reference counting. _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
