Subj : Re: How to manage time-slicing in Pthreads programs?
To   : comp.programming.threads
From : Marcin 'Qrczak' Kowalczyk
Date : Mon Feb 21 2005 11:35 am

"David Schwartz" <davids@webmaster.com> writes:

>> (I can't just use OS threads because an efficient multithreaded GC is
>> too hard, because they don't scale to a large number of threads, and
>> because it would require too much synchronization in various places -
>> currently each C snippet is automatically a critical section, which is
>> useful for making some primitives safe.)
>
>     I think you're starting out wrong. By doing that, you get reduced 
> concurrency for no reason. It's data that needs to be protected, not code.

Data protection is put in the code. It's just a matter of viewpoint
how we talk about it, not of the reality.

I disagree that it is "for no reason". There would be lots of problems
with using pthreads or another threading library. For example how
would I implement asynchronous signals with my intended semantics
of blocking/unblocking? With my approach it can be done with no
additional overhead: we can poke inside a thread structure while the
thread is preempted and change its "code pointer". But with pthreads
it would make no sense to acquire a mutex (to check the state with
memory synchronization) at the beginning of each function call!
It's just unimplementable without horrible overheads.

How to implement read-write locks with promotion? POSIX provides
rwlocks but without promotion. So I have a choice: either give up
and cripple features because of POSIX limitations, or make them
from scratch using mutexes, explicit queues consisting of flags
and dynamically created condition variables (in order to wake up
a particular thread) etc.

Using pthreads would require to choose between excessive synchronization
(whic is not needed to that amount with emulated threads) and risking
crashes caused by multithreading in a language which is otherwise safe.
For example checking the index range of a resizable array would either
have to acquire a mutex for each operation, or risk heap corruption in
case another thread resizes the array concurrently, or make a resizable
array from an atomically updated pointer to a non-resizable array, with
two range checks in effect. The first two choices are unacceptable, and
with the third (an equivalent of what happens in Java/.NET) it would be
a pity that multithreading slows down array operations.

>>> it's wrong for socket discovery,
>>
>> What is this?
>
>     Determining which sockets are ready for I/O.

I use epoll/poll/select for this (internally; from the point of view
of the programmer there are just threads and blocking I/O).

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

.