Op Thu, 24 Jun 2010, schreef Michael Schnell:
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.
If you are special things, it is reaosnable to ask special attention by
the one who does those things. If there is an easy fix, feel free to
propose it.
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.
Yes, but in a multi-cpu system giving up the timeslice is a very bad idea,
because the lock might be released a few clock cycles later by the other
cpu; you would waste the rest of time slice while you could be crunching.
Daniël
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
