> If you are doing concurrent programming right you don't need compare and sweep synchronization because you aren't sharing memory across different threads.
By definition, you aren't doing concurrent programming if you aren't doing shared writes.
> By definition, you aren't doing concurrent programming if you aren't doing shared writes.
I don't understand what you mean but I like Robert Pike's take on concurrency:
"concurrency is the composition of independently executing processes"[1]
As a specific example if you don't want code to block while you're waiting for HTTP requests to finish you're going to be writing concurrent code. I don't understand how that involves "shared writes" but maybe you can explain further? I can write concurrent code that shares no memory, and I can print log statements that show me it's executing concurrently, so I think you may be mistaken.
> "concurrency is the composition of independently executing processes"[1]
Yes, and that implies shared writes.
> As a specific example if you don't want code to block while you're waiting for HTTP requests to finish you're going to be writing concurrent code. I don't understand how that involves "shared writes" but maybe you can explain further?
That's not really concurrent code, because there's a clear happens-before relationship between making the request and executing the callback "onComplete", so the original request and the ensuing onComplete continuation is serial.
However, this particular example uses concurrency under the hood to work. You don't know when the request will be ready and you need to execute this onComplete and the next specified onComplete (if multiple callbacks are specified), so under the hood you need a shared atomic reference and synchronization by means of one or multiple CAS instructions, which also imply memory barriers and so on.
I agree with bad_user's points, but I would like to add my own phrasing in support of his points.
Concurrency with "independently executing processes" are not strictly independent. There must be some communication between the processes, otherwise they cannot coordinate to achieve the same task. A typical mechanism is to have a shared queue between the processes as the only point of communication - use of that queue will involve "shared writes".
People build abstractions on top of such mechanisms which hide these shared writes, but they are still there. And that is part of bad_user's point: even though you, yourself, are not actually writing the code for a "shared write", you must call code that eventually performs one.
By definition, you aren't doing concurrent programming if you aren't doing shared writes.