GDB 6.0 and FreeBSD threads

Julian Elischer julian at elischer.org
Mon Mar 29 20:40:51 PST 2004


Niall Douglas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 29 Mar 2004 at 23:41, Petri Helenius wrote:
> 
> 
>>>Here's a thought - surely on a M:N threading implementation the
>>>kernel and user side library can automatically optimise which threads
>>>don't need to be system scope? They could do this by maintaining a 
>>> 
>>
>>I would hate to see this happen. The added complexity and 
>>unpredictability would make implementations harder because you would
>>have to account for an optimizer which tries to think what´s best for
>>the crappy application/programmer who does not know what he wants.
> 
> 
> As I grow older, I believe that programmers should tell the computer 
> what to do rather than how to do it. To tune the dependencies between 
> threads waiting on each other is extremely tough, so tough most 
> programmers don't bother. A 1:1 scheduler is usually written with the 
> process side dumb as to what's happening in the scheduler so the 
> kernel doesn't know about an impending i/o block or wait condition 
> until it's traversed into kernel space.
> 
> Basically what I'm suggesting is a form of spin lock for i/o points 
> and greater devolvement of i/o operations out of the kernel. In 
> something like the hurd this is supposed to be the whole point, but 
> then that project has taken an age.
> 
> I think we're really early into multithreading technology. We're very 
> far from the perfect scheduler which could make multithreaded systems 
> considerably faster than previous ones - there are user-land threaded 
> i/o systems which gave Apache a massive speedup. An M:N system is 
> clearly the future and we'll make mistakes in our first few attempts. 
> However we'll get there eventually.
> 
> 
>>Why not just run all threads SCOPE_PROCESS? Then the system will do
>>that for you.
> 
> 
> The pthreads implementations I've seen won't utilise more than one 
> processor unless it's SCOPE_SYSTEM. The obviates the reason most 
> people use threads, hence the success of the 1:1 model which is a 
> very blunt axe.

Our definition of "process_scope" is that it runs with the weight of
one process TIMES THE REQUESTED CONCURRANCY which is limmited to the
number of CPUs.
i.e. even in SCOPE PROCESS programs, teh default concurrancy is NCPU
and we allow up to that number of threads to run at any one time, however we 
don't allow the process to use NTHREADS slots on the run queue. Only up
to NCONCURANCY (which is limmitted to NCPU) of the threads are allowed
to contend with other processes at any one time. The other threads can only 
contend with those threads to be one of teh lucky ones competing.
The result is that teh process can have 100% ofthe cpu when there is no
competition but if there is competition it has to compete on an
"approximatly" equal footing with the other processes.
(sure it's weight is amplified by NCPU but that is usually much less than
NTHREADS).
  (there is also thread afffinity (not yet implemented) where a process that has 
excess quantum when it's running thread sleeps has first dibs on the remainder 
of it's quantum to use on other threads)

> 
> 
>>The great advantage of process scope threads is the fact that you can
>>hand over a mutex without going trough a process switch.
> 
> 
> I have a hand written mutex which avoids the kernel completely except 
> to sleep and wake the thread. This process could also avoid the 
> kernel as it's really a process-internal issue and my spin count code 
> avoids that completely on low-contention locks. However, a thread 
> context switch within the same process map is far less costly than a 
> process context switch, even if it must enter the kernel - if this 
> weren't so, all those diehard Unix fans wouldn't be having to face up 
> to the death of the process forking model.

Ah but Linux and Solaris have gone the other way..
They have abandonned M:N in favour of N:N with kernel based thread suspension.

> 
> Cheers,


-- 
+------------------------------------+       ______ _  __
|   __--_|\  Julian Elischer         |       \     U \/ / hard at work in
|  /       \ julian at elischer.org     +------>x   USA    \ a very strange
| (   OZ    )                                \___   ___ | country !
+- X_.---._/    presently in San Francisco       \_/   \\
           v



More information about the freebsd-threads mailing list