3 ms·

I'd say the exact opposite. Race-conditions in parallelism are where the classic problems lie. We aren't going to agree here, but you sounded like you thought

I'd say the exact opposite. Race-conditions in parallelism are where the classic problems lie. We aren't going to agree here, but you sounded like you thought your position was axiomatic or something, and that's what I disagree with. Meanwhile I am content that we may have different preferences, that's not a problem.

eropple 9y ago
The problem, in every case I can think of (and it intuitively seems true), is continuation, whether it's done in software with coroutines or in hardware with process scheduling/threads. Which is a concurrency problem rather than a parallelism problem, which then expands to "are problems of linearizability concurrency or parallelism?". Which might be a more settled way to answer the question in a CS manner. Can you describe a race condition that cannot be replicated on a single thread with either preemptive or cooperative multitasking/coroutines? I'm racking my brain and can't come up with one. If your coroutines are deterministically given time, then I guess you can avoid race conditions, but "are my coroutines deterministic" seems like a really difficult thing to conclusively prove in all cases (like, just add network I/O latency), and the conceptual barrier remains the same whether they're deterministic or not. (Edit: a friend just noted the possibility of writing to memory/disk and reading halfway through, and if you don't have atomic writes that's true, but you can have preemptive, single-process multitasking that interrupts mid-write; that's why we have file system lockfiles, isn't it?) I use node-async-locks when writing JavaScript sometimes if I have to deal with shared state, because, hey, I might have to await something and come back to this later. (Obviously I try not to, because duh, but sometimes you're stuck with it and can't immutable-all-the-things. So you define a critical section and do your thing.)
eropple 9y ago
Coming back to this, I'd really like to direct your attention to my reply. Am I missing something with regards to this?

eropple 9y ago

The problem, in every case I can think of (and it intuitively seems true), is continuation, whether it's done in software with coroutines or in hardware with process scheduling/threads. Which is a concurrency problem rather than a parallelism problem, which then expands to "are problems of linearizability concurrency or parallelism?". Which might be a more settled way to answer the question in a CS manner. Can you describe a race condition that cannot be replicated on a single thread with either preemptive or cooperative multitasking/coroutines? I'm racking my brain and can't come up with one. If your coroutines are deterministically given time, then I guess you can avoid race conditions, but "are my coroutines deterministic" seems like a really difficult thing to conclusively prove in all cases (like, just add network I/O latency), and the conceptual barrier remains the same whether they're deterministic or not. (Edit: a friend just noted the possibility of writing to memory/disk and reading halfway through, and if you don't have atomic writes that's true, but you can have preemptive, single-process multitasking that interrupts mid-write; that's why we have file system lockfiles, isn't it?) I use node-async-locks when writing JavaScript sometimes if I have to deal with shared state, because, hey, I might have to await something and come back to this later. (Obviously I try not to, because duh, but sometimes you're stuck with it and can't immutable-all-the-things. So you define a critical section and do your thing.)

eropple 9y ago

Coming back to this, I'd really like to direct your attention to my reply. Am I missing something with regards to this?