
On the duality of operating system structures - platz
http://blog.acolyer.org/2014/12/08/on-the-duality-of-operating-system-structures/
======
westoncb
While they may be duals formally, they still have significant differences in
how individuals are able to model them mentally.

I've felt the appeal for the message passing style for a while, but always
disliked the additional bulk/rigidity of frameworks for it. Recently though,
I've been thinking about a concept for program organization based on 'domains'
and 'converters,' that's (in part) an extremely minimal message passing system
in Java. There's a little essay on my github for the project:
[https://github.com/westoncb/Domain-slash-
Converter](https://github.com/westoncb/Domain-slash-Converter)

------
charlieflowers
If most developers knew both sides of the coin, then most projects would
choose which approach was a better fit for their situation.

But what happens is, developers work for years only knowing one way, thinking
it is the only way. They start to notice problems/friction/"code smells", and
they follow the resulting thought process till they eventually discover the
other way.

At this point, they might mistakenly think the newly discovered way better in
all cases. They might also mistakenly think it is their invention.

Learning theory really is a powerful shortcut.

------
exDM69
Why not both?

Locking (spinlocks, mutexes and conditions) is a building block for higher
level concurrency primitives just as "goto" is a necessary building block for
higher level control flow patterns.

You need locking to implement message passing anyway. Although message passing
can be done in lock free manner (using atomics) if busy waiting is good
enough, but that is not suitable for all (most?) cases.

I see this philosophical argument against locking often used as an excuse for
not learning how to use mutexes and conditions properly. It might not be
practical for all higher level tasks you need to do but there's no excuse not
to learn how it works (and that needs practice, intuition is almost useless
here). For low level concurrency work, you need to know how to use locking
_correctly_.

------
dkarapetyan
Study the history and the theory because otherwise you are running around like
a chicken with its head cut off. We need more articles like this.

------
platz
Regarding duality - obligatory meijer reference - this time on async and
observables. main point: any one design could very well be isomorphic to a
whole range of options in the design space -
[https://www.youtube.com/watch?v=pOl4E8x3fmw&feature=youtu.be...](https://www.youtube.com/watch?v=pOl4E8x3fmw&feature=youtu.be&t=50m6s)

~~~
enord
Also regarding duality - just because there is a proof of duality between
designs it does not follow that they design the same thing at all.

Classic example from CT: In sets (well, the _category of sets and maps_ but
still...), the cartesian product is _dual_ to the disjoint union (sum type,
variant record etc.) From this, anything proven about cartesian products
(which is a lot, as it is fundamental to most of set-theory) proves
_something_ about the disjoint union through the duality. What it actually
proves about disjouint unions is open to interpretation on a proof by proof
basis.

Which is to say: The consequences of duality are rich and powerful, but they
are often non-obvious and for systems with many moving parts almost certainly
non-trivial.

~~~
platz
Good point

------
tinco
Note that this article is the first in a 5 part mini-series, the other
articles are well worth reading too.

I like to think that the conclusion is that Haskell is the most perfect
language for concurrent programming, but maybe that's my rose coloured
glasses.

~~~
platz
I think you may have over-indexed on the context that is most appropriate for
your use-case.

*edit - The core point IMHO: You have to build on your system's primatives. If it can afford haskell, great (And in many cases we associate with general programming, this may be true) - but I don't think we should say it's the case catagorically.

------
platz
Another comment in this article prompted a lookup of the difference bewteen
message passing and event architectures..
[http://programmers.stackexchange.com/questions/146586/merits...](http://programmers.stackexchange.com/questions/146586/merits-
of-a-message-passing-system-vs-an-event-based-system)

------
signa11
i was wondering if the 'style' of current mostly NUMA type server-hardware
platforms, favor one approach over another. for example, when no more GHz
improvements etc. are possible it _seems_ that message-passing _may_ tend
towards a better utilization of available resources than locking (which might
cause hundreds of wasted cycles all over the place)

