GDB 6.0 and FreeBSD threads

David Xu davidxu at freebsd.org
Mon Mar 29 18:53:37 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.
>
>  
>
>>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.
>
This is ideal case, in real world, a thread switch could cause a thread 
from other process
be scheduled,  this would cause CR3 on i386 to be reloaded for a new 
process, even when
you are handing a pthread mutex off  to a thread in same process.

>Cheers,
>Niall
>
>
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2
>
>iQA/AwUBQGjMOcEcvDLFGKbPEQKMKACfZIoDBT+br69MgbW+sfgz9HANr0MAoKvn
>yldlx8YuekW9J9u4Gv6E54zU
>=LDUT
>-----END PGP SIGNATURE-----
>_______________________________________________
>freebsd-threads at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-threads
>To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
>
>
>  
>




More information about the freebsd-threads mailing list