chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Re: An alternative thread system?


From: Alaric Snell-Pym
Subject: Re: [Chicken-users] Re: An alternative thread system?
Date: Tue, 12 Aug 2008 00:23:48 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Some people wrote:
[Threads are a pain, much better to stick to message passing]

Some other people wrote:
[But but but processes communicating with pipes is the same as
threads using message passing primitives]

Well, yes. To a certain extent, threads vs. processes is a
meanginless distinction; processes can share memory, threads can
communicate over pipe-like things. But processes enforce isolation of
mutable state unless you explicitly go and share memory.

What's at issue here, really, are message passing versus shared-
structure programming models.

And I concur with Elf and others: message passing is, by far, the
better model, since shared structures are a pain to get right. Full
disclosure: I've written complex high-performance threaded apps in
Java... and ended up splitting them out into separate processes, for
the following reasons:

1) They could be easily moved to different machines to cope with
increasing load, and communicate over TCP
2) It limited the consequences of a JVM segfaulting (which, also,
seemed to happen less the less threads we ran per JVM, creating a
rather quadratic increase in system availability)
3) It let me do rolling replacements of parts of the system with new
code. Replace each worker process in turn so we're never down more
than one. Replacing the old threaded code was "take system down,
bring new system up, quickly roll the old .jar back if it doesn't
start and run properly"

The fact that processes gave us simple control of communication, by
making it explicit and preventing threads from accidentally
interacting through global variables, would have been a benefit were
I not the kind of incredibly elite programmer who actually knows how
to write concurrent shared-state code properly *and* the sole
developer *and* that I managed to get away with telling the
management that I wouldn't work on certain bits of the system without
taking a long time to think about it first, regardless of their
important business requirements. But this is very much not
representative of most development teams...

However, they do have some uses - after all, a message queue is a
form of shared structure in the first place, and there are uses for a
limited set of other *simple* shared structures where the effort of
developing the thing to work correctly in all situations is worth it
for the performance benefits (guaranteed-unique serial number
generators, shared caches, that sort of thing). But definitely in the
realm of "concurrent structure programmers produce libraries that the
rest of us use".

On an orthogonal level, Elf has also pointed out that there are OS-
level implications of the choice between threads and processes,
regarding signal handling and blocking and so on. But this is a
separate issue. If a threaded programming model is what you want by
the OS makes it painful to do so, you can always make your app store
all its data in a mmaped segment then fork off children then have
them mmap in the parent's memory to get the same effect as threads,
but with independent signal state and scheduling and so on.

ABS

- --
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/?author=4

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkigygUACgkQRgz/WHNxCGpWIACfZ6kRuQ2G7sGRaVp7kqpDpzZD
49EAnjdA6/6euM2tWDD9qePK9cQQan63
=pVAh
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]