Date: Mon, 29 Mar 2004 20:48:00 +0100 From: "Niall Douglas" <s_sourceforge@nedprod.com> To: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads Message-ID: <40688B80.18775.48ADA9C@localhost> In-Reply-To: <4067D344.8030403@elischer.org> References: <4067CC9B.8940.1A12F51@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 Mar 2004 at 23:41, Julian Elischer wrote: > On this topic, There are 3 separate compatible threads libraries > Libc_r is only SCOPE_PROCESS, libpthreads implements SCOPE_PROCESS and > SCOPE_SYSTEM, and libthr is only SCOPE_SYSTEM. Do you run ALL threads > as scope system, or only some? We don't recommend COPE_SYSTEM unless > it's really needed (for example to make some threads run at > higher/lower priorities) as they are less efficient. Benchmark your > app with both types. (I think Linux is only SCOPE_SYSTEM). The project also runs on Windows so up till now it's been assumed SCOPE_SYSTEM. That's too much for some of the threads so I'm very open to having some of them run as in-process threads. I had this in mind when designing the thread class, it's an easy extension. 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 sleep & i/o history for each thread, noting when which threads run concurrently, which i/o dependencies exist between threads and from that dynamically rescope the thread plus perform dynamic priority boosting to minimise sleeps. Indeed, if the kernel scheduler felt it was being overtaxed, more threads could be moved in-process. To me there is little point investing in all the complexity of a M:N implementation if you don't implement such optimisation features - otherwise the substantial amounts of extra code cause things to run slower due to sheer binary size. Of course this subtly breaks POSIX compliance as you ignore what the application asks for - it also requires an inprocess scheduler which works identically to the kernel one, and currently libc_r doesn't do that. > > BTW on my FreeBSD v5.2.1 the library is called libkse, not > > libpthread which doesn't exist. > > That's the problem with the fact that this field moving so quickly. > You should probably upgrade to -current so that you can debug these > threads. and get reeady for yur app to run on 5.3. I had thought, perhaps foolishly, that since MacOS X has good threading support and it comes from FreeBSD then therefore FreeBSD must have mature threading support. You seem to have the functionality okay, just none of the tools quite yet. Writing threaded code is hard without a debugger! And for some strange reason, my sockets class hangs on FreeBSD when it works fine everywhere else. As all the blocking i/o in my project is done by threads, I have given up trying to debug it. > directly to david.. it's still in prerelease. > Also, you MUST be running TODAY'S -current so you'll need to upgrade. > Sorry but it's an area of active development. The roadmap says v5.3 beta will be out 1st March. I take it this has slipped? What precisely will be changing in v5.3? Is http://www.freebsd.org/releases/5.3R/todo.html and http://kerneltrap.org/node/view/1898 representative? Lastly, does the new scheduler give better performance on uniprocessor machines over the old one? I actually compiled it out for my kernel assuming a SMP kernel is slower on uniprocessor. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQGh9cMEcvDLFGKbPEQJvaQCeIPK72w6KBEyL1RrOHyiHI+RcMA4AoK5R VnHm2EdScFqAKFyXHfRZrphP =/gIb -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40688B80.18775.48ADA9C>