Meyer, OO and concurrency

>The non-shared memory, pure copying asynchronous message
>passing, paradigm is
>far easier to program (witness all the web applications,
>virtually all use
>non-shared memory (ie separated processors) and pure
>message passing (defined by RFC's))
>and very easy to understand.
More evidence that shared memory is evil:
---
2. We recently read that the fix for the Hyper-Threading
vulnerability is considered non-trivial. Why is that?
John Baldwin: The issue found with HT is that the two
logical CPUs on a single core share the same caches and as
a result there are ways for one logical CPU to spy on the
activities of the other CPU in the same core. The proposed
fixes involve ways of guaranteeing that all of threads on
a single core are all allowed to spy on each other. For
example, one policy is that only threads with the same
user ID should be allowed to run together no the same
core. The problem is that right now FreeBSD treats logical
CPUs as separate CPUs and schedules available threads on
the first CPU that becomes available. It would be a bit of
work to make the scheduler more aware of logical CPUs and
to schedule threads with respect to UIDs, etc.
Robert N M Watson: It's worth observing that this is a
serious vulnerability across a range of operating systems,
not just FreeBSD. If you allow untrusted users on the same
system as an SSH daemon, you're at risk, which affects
everyone from desktop users, to ISPs, to military
end-users. It's also a very hard problem to solve -- we're
looking at it from the perspective of improving the
scheduler, bringing in OpenSSL updates to limit timing
attacks, and obviously we're hoping that CPU vendors take
this opportunity to explore how to harden CPU
architectures against this sort of attack. Because this
vulnerability isn't just about scheduling, crypto, or
hyper-threading, a lot of hard work will have to into a
long term solutions.
---
From http://www.osnews.com/story.php?news_id=10951
Regards,
Marc