On Don, 2011-08-18 at 19:09 -0400, Rich Felker wrote:
[....]
> The problem goes away nicely as soon as you give up the idea that
> threads are the work of the devil; you end up with several threads
Threads are as devilish as processes - the only difference is that
the threads in one process share the very same data.
> doing something like the above, and when you have a case that needs to
> do something that can't complete immediately, you pass the work off to
> another thread.
>
> Threads got a really bad name from the bloat of popular
> implementations. One of my design goals in musl has been to make
> threads so light and inexpensive (in both code size and runtime memory
> and cpy time overhead) that you don't have to think twice about using
> them.
That's probably the biggest problem with threads - (some) people throw
them in for the above problem and forget that they have to *think* about
(and, thus, design) the synchronization between them.
Even if the data can be/is separated so that no (explicit)
synchronization is needed, you have to - at least - think about it at
the point of coding the first pthread_create() and keep it in mind
until the last of them is gone.
And the really nasty issue is that one usually doesn't see any
synchronization problems on "large" hardware (read: current desktops,
servers) with very small load.
And when it blows in a year (with 20 threads doing God-knows-what
because they are so nice and easy to use), it's a real mess .....
If you mess up the data separation with processes, you see it
immediately on the first test runs (because it either doesn't work
or a process seg-faults or ...).
If you mess the data-non-separation up with threads, you see it in the
field on the first larger installations ages later.
Ooops, somewhat off-topic.
Bernd
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
