Linux Kernel Network Subsystem Patching

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Wed Jan 22 14:25:59 UTC 2014


On Tue, Jan 21, 2014 at 06:36:38PM -0500, Bob Jonkman wrote:
> Even a single, 1-core processor can run multi-threaded code, can't it?
> I imagine by the OS timeslicing.  The Amiga was the computer I saw
> where someone pointed out the pitfalls of multi-threading, and I'm
> sure that didn't have multi-core. But I expect that code that runs
> multi-threaded on a 1-core processor would run better on a multi-core
> processor.

Sure.  The system selects among all the runnable threads and distributes
them among the available CPUs.

The amiga was one of the first consumer systems to have preemptive
multitasking (that means the OS decides when to switch between threads.
Windows 95 and up and all the Windows NT line work this way, as does
OS/2, and of course all the unix style systems), rather then cooporative
multitasking (where the application decides when to stop running and let
another task have a chance to run.  Windows 1 through 3.11 worked this
way, as did Mac OS until they switched to the unixish nextstep based
Mac OS X).  The big pitfall on the Amiga was actually that it had no
memory protection at all, so it had to way to isolate applications from
each other.  This means a bad pointer in one program could actually just
as easily corrupt memory in another program as in itself.  Amazingly it
was very stable so apparently amiga application developers were extremely
careful.  The multitasking was not really the issue.

Multitasking simply means an OS that is capable of running more than
one thread at a time.  So not DOS for example.

> How much code tweaking is necessary for a multi-threaded program to
> take advantage of multiple cores? Or does the compiler take care of that?

The OS takes care of that.  The compiler has nothing to do with it.

Now there have certainly been things that did their own threading inside
the application, in which case to the OS it would actually look like a
single threaded process, in which case the OS can't help you and you
do not get to use more than one CPU.  That doesn't really seem to be
done anymore now that pretty much every OS supports threading in the
native C library, and in the case of all the unix style systems, they
all support the standard posix thread interface, which makes the code
fairly easy to make portable (except of course to windows, which does
things in a completely different way).

Of course sometimes people did things without threads to make the code
simpler, or avoid portability issues, such as apache, which traditionally
simply forks a new copy of itself for each connection, rather than use
threads in one process to handle them.  Part of it is that it runs on
practically every OS, and a standard threading model doesn't always exist,
and also when using apache modules, sometimes things have bugs and can
break, or a module uses a library that isn't thread safe (meaning the
library has functions that can't be called multiple times at once due
to keeping internal state, or globab variables in the library), so by
using a new copy each time you avoid those issues.  For good measure
apache tends to have the copy commit suicide after handling a certain
number of requests, just in case anything got corrupted, so that any
problems don't hang around too long.  There certainly exists threaded
versions of the apache server, but many of the modules explicitly don't
work with it.

OK, that seems long enough already.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list