[fpc-devel] Threading support and C library under Linux/Unix

[Florian Klaempfl]

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.