Posts in Castle DesignStudy
- Castle DesignStudy, CastleBlogs
In Castle, one can dynamically connect components and send “events” over those connections. Typically this is done as an action on an incoming message (see: The Actor Model). And depending on ‘The Machinery (ToDo)’, those events can be queued. It is this combination that can result in a beautiful Heisenbug.
First, let’s explain the Heisenbug, before we give an example. Then we analyze it, show how to improve the code, and finally formulate a requirement to prevent & detect this kind of bug in Castle.
Concurrent Computing Concepts
- Castle DesignStudy
Sooner as we realize, even embedded systems will have piles & heaps of cores, as I described in
“Keep those cores busy!”. Castle should make it easy to write code for all of them: not to keep them busy, but to maximize
speed up [useCase: In Castle is easy to use th... (U_ManyCore)]. I also showed that threads do not scale well for CPU-bound (embedded)
systems. Last, I introduced some (more) concurrency abstractions. Some are great, but they often do not fit
nicely in existing languages.
Still, as Castle is a new language, we have the opportunity to select such a concept and incorporate it into the language.
In this blog, we explore a bit of theory. I will focus on semantics and the possibilities to implement them efficiently. The exact syntax will come later.