there is interleaving there, you are not guaranteed there is parallelism
unless those get mapped to different processors
it's also worth pointing out that those definitions are only valid in the context of the talk, if we were talking about, say, distributed systems, I'd use a different definition of concurrency
which is why I gave the definitions I was working with at the start of the talk
not that I entirely came up with them though, Simon Marlow in Parallel and Concurrent Programming in Haskell uses the same definition, and
Concurrency is not parallelism on the Go (!) blog, uses a very similar one
that being said, concurrent data structures can mean different things as well
although I think in scala the two things I'm thinking of are actually correctly named as concurrent data structures (like Maps) and parallel collections
anyway, in case you're wondering, the most general definition of concurrency I use is when working with distributed systems
where you would say that there is no total order on events
there is a partial order (we can say that some events happened before other), but not a total order: for some pairs of events we don't know if
a < b or b < a (where < in this case is happened before), and therefore a and b are concurrent
btw keep up the great work on tracing! I haven't commented on the PR but I'm following it :)
and thanks! excited to get it to a usable state
I like that definition though. I think you can interpret both the interleaving of events and the interaction of threads through that definition
like, at the level of the JVM threads are also being interleaved, just like fibers are (although through different mechanisms)
so conceptually threads aren't really any more "parallel" than fibers are (although there are potential implications from the memory model)
but yeah,
happens before is more general (Lamport really is a genius), but doesn't help with the aspect that matters of the talk, i.e. the logical thread as a structuring abstraction
just the concept that you have multiple synchronous sequences of steps that actually abstract over interleaving
and in that sense
java.lang.Thread and Fiber are not any different
so in short no, when I'm giving definitions in part 1, I'm not talking about fibers specifically
and if you see that "sequence of step" definition applies to both
it does not apply to akka actors, for example, so really I am talking about the "thread" abstraction
then in part 2, I start talking about processes vs Thread vs fibers
part of the problem with this topic is this layer structure, depending on where you're looking at things change, hence why the "chapter" structure of the talk
r is it a general term
also to clarify, it depends on who's using that term, it's overloaded and often it means something even weaker than fiber. But in my talk, I meant the general idea as it applies to OS processes, Thread, fibers, and even manually stepped coroutines (like the one in PureConc in ce3)
so on the topic of the layering structure, I may have misunderstood this, you mentioned that Threads are mapped M:N to processes. Is this accurate for the purposes of scheduling? My understanding is that processes serve as a "grouping" mechanism for threads, but ultimately threads are scheduled on the CPUs, and not necessarily processes
I should take a look at the work being done for CE3
OS level threads are scheduled directly on the cpu
at least in modern OS'es, earlier versions had the actual M:N scheduling
so I decided to go with this description, even though is outdated, for greater conceptual clarity
Why do i get stack overflow here, isnt flatmap suppose to be stack safe?
def loop: F[Unit] = {
x.state.read.flatMap {
case CommChannel.Ready =>
log("ready")
case CommChannel.Disconnected =>
log("disconnect")
case CommChannel.Other(content) =>
log(s"other $content")
case a: CommChannel.ActionRequired[F] =>
log(s"action required: ${a.content}") *>
read.flatMap(x => a.response.complete(x))
} *> loop
}
loop.start *> Sync[F].unit(state is MVar)
should i use >> by default?
huh also, if
Temporal <: Concurrent, does that mean any code wanting to read the current time also gains the ability to do concurrency? That would be a big drawback for parametric reasoning IMO
