3 ms·

Great, thanks! There are books online for free, e.g. https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf

• kragen 3y ago
  sorry for the delay i don't know that much about concurrency in general, so take this with a grain of salt i feel like monitors are potentially an improvement over bare locks, but they tend to perform poorly in manycore settings and are still vulnerable to deadlock, perhaps more so due to their implicit nature. (i see that you point this out with respect to java, and also that it doesn't really have monitors.) fundamentally, blocking synchronization of any kind is incompatible with modularity you misspelled brinch (rip) there are lots of versions of actors, and the most influential one effectively didn't have any concurrency at all, so it's important to disambiguate in the text that you're talking about the one in agha's 01985 dissertation, which is also very influential. also your footnote says it's from "1986"; is that a different document by agha with the same title? objects with their own threads (like concurrent actors or like processes in csp or erlang) are not the same thing as monitors, contrary to your assertion in the 'concurrency in oberon' section. there is a well-known duality between message passing between threads and control passing between monitors, but the mechanisms have quite different ergonomics and common failure modes it's surprising that in a discussion that surveys original-modula, modula-2, csp, erlang, active oberon, c, c++, concurrent pascal, object pascal, superpascal, joyce, newsqueak, old squeak, alef, limbo, golang, java, and ada, you didn't mention javascript at all. in browsers and node, javascript's concurrency model was originally that of original oberon — each event handler runs to completion in succession — which strongly suggests that the concurrency facilities it has added more recently might be worth a look. those are python-like async/await, sometimes caricatured as 'colored functions', and web workers. also it might be worthwhile to at least mention the π-calculus my uninformed viewpoint is that js, erlang, haskell with its stm, and (non-async!) rust are the languages with the most promising approaches to the concurrency problem. all four of them work hard to be safe (unlike the entire rest of the js language), though i think their concurrency safety guarantees are all to some degree fragile. except maybe haskell, which i haven't tried your reference [31] https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/ https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... doesn't purport to show that no single concurrency construct is adequate, as you claim, or even that communication channels are inadequate; rather, it argues that the implementation in golang of that concept is inadequate, because golang implements them inefficiently, because it can't garbage-collect processes, because there are some design errors, and that because golang also offers other concurrency constructs (as you propose for oberon+), it's hard to avoid concurrency bugs. though certainly not conclusive evidence, this runs strongly against the conclusion you are using it to argue for also your bibliography incorrectly abbreviates 'per brinch hansen' as 'hansen, p. b.' rather than 'brinch hansen, p.' a few times i hope this is helpful, and i'm glad to see you're exploring how to solve this problem! feel free to copy or excerpt my comments elsewhere if you think it would be useful
  • deleted 3y ago
    [deleted]
  • Rochus 3y ago
    Thank you very much for your time and your feedback which I really appreciate. > but they tend to perform poorly in manycore settings and are still vulnerable to deadlock [..] fundamentally, blocking synchronization of any kind is incompatible with modularity Do you have references for this? With the selected version of signals (only an await procedure, no explicit signal required), the only way for a deadlock from my point of view is when a protected procedure calls directly or indirectly another protected procedure of the same monitor, thus trying to acquire the same lock twice. But this can be detected by the compiler. Or did I miss something? > you're talking about the one in agha's 01985 dissertation My reference is this book: https://direct.mit.edu/books/monograph/4794/ActorsA-Model-of-Concurrent-Computation-in https://direct.mit.edu/books/monograph/4794/ActorsA-Model-of.... It's essentially his PhD released as an MIT press book (at least I didn't see significant differences). But I prefer to reference books over PhDs if possible. > objects with their own threads [..] are not the same thing as monitors I'm not aware I claimed this. Will check whether the formulation is misleading. Actually I wanted to point out that the "objects with threads" in Active Oberon give little added value and are not "active objects" at all. > you didn't mention javascript at all Well, the intention was not to have a general discussion about concurrency in all programming languages; I'm primarily interested in the relatives of Oberon, plus a selection of languages based on CSP. I just mentioned Erlang because it is a prominent example of an Actor language. But I will have a look at more recent JS developments for ideas compatible with Oberon. > javascript's concurrency model was originally that of original oberon Just because of the message delegation/handler concept (which existed before Oberon)? I wasn't aware that there is a direct connection of JS and Oberon (it is not even mentioned in the 2020 JS HOPL paper). > are the languages with the most promising approaches to the concurrency problem Do you think that JS concurrency is better than Go concurrency, i.e. channels aren't worthwhile at all? Why? > it might be worthwhile to at least mention the π-calculus From my perspective, that's sufficiently covered by [13], as far as the concepts might be useful for Oberon+. Which relevant idea do you think is specifically missing? > your reference [31] doesn't purport to show that no single concurrency construct is adequate The paper explicitly states "Unfortunately, as it stands, there are simply a surprising amount of problems that are solved better with traditional synchronization primitives than with Go’s version of CSP. [..] The summary here is that you will be using traditional synchronization primitives in addition to channels if you want to do anything real", from which I conclude that channels alone are not good enough; this conclusion is also supported by [32], where one of the tables demonstrates that the analyzed projects use low-level primitives twice as much as channels. I agree with the author that there are problems which can more elegantly be solved with classic synchronisation (including monitors), regardless of possible design issues of Go; we could use channels to emulate those (as demonstrated), but for efficiency reasons I preferred to directly add monitors (as Go did with adding low-level primitives instead). I think monitors are still better than the Go sync package, and if everything else fails Oberon+ could access pthreads by FFI. But that's actually the main point where more thinking and discussions are required.