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

[Daniël Mantione]

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