Subject: Re: So I'll bite. M:N w/o SA - how? (stick to 1:N with Pth!)
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.org>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 02/22/2007 16:00:45
At Thu, 22 Feb 2007 12:58:21 -0800,
Bucky Katz wrote:
> I did a wc on our code base yesterday. The current version of the
> application runs just shy of 1.1 million lines, not including optional
I don't think it matters how big it is, except for how much more likely
this makes it to suffer concurrency related bugs. :-)
> It's designed to use preemptive concurrency.
I'm not sure I understand how that could preclude trying it with a 1:N
threading library, particularly one that provided wrappers for all the
system calls that are likely to block the whole process.
If your code is all in C then it would only take as long as it takes to
re-compile it all to find out if it would work with Pth, or could at
least be easily adapted to work with Pth, for example.
At the most you will probably need to add some calls to yield thread
execution in key places, though if your application is as well
understood by your programmers as you tend to suggest it is then that
should be a relatively easy and perhaps even almost mechanical task
(though take heed of the warnings in the Pth manual about this!).
You have yourself admitted that a fully user-land thread implementation
will likely have far better performance (obviously so long as it doesn't
block in the wrong places and for the wrong reasons). Such a model
obviously implies 1:N threading and event driven I/O wrappers such as
those offered by Pth. In fact you've said that context switching is the
one big performance issue on your current platform and so the potential
benefits of a user-land-only thread implementation may be very high.
You have also agreed that true concurrency makes programming difficult,
and though you state nothing about the quality of your code nor its
current level of reliability I find it nearly impossible to believe that
eliminating true concurrency would not at least improve the reliability
of such a gargantuan 1.1-million line application somewhat, no matter
how mature it is.
So, in the context of what you say is your specific job of getting your
application to run efficiently on NetBSD (on your current hardware
platform) then it would seem that investigating the use of a fully
user-land-only thread library would likely fall within your brief.
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <email@example.com>
Planix, Inc. <firstname.lastname@example.org> Secrets of the Weird <email@example.com>