Re: Is Parallel Programming Hard, And, If So, What Can You Do About It?

On 5/20/2025 11:19 AM, BGB wrote:

On 5/20/2025 8:53 AM, Scott Lurndal wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 19 May 2025 21:33:11 +0000, quadibloc wrote:
>

Parallel programming isn't "hard" or "easy".

>
Concurrent processes/threads, running either fully concurrently on
separate processors, or with asynchronous preemption on shared processors,
are hard to program.

>
Clearly you are someone who has never done it.

>
In my case...
>
Personally, I rarely use multi-threading, and when I do, it is usually in the form of using mutex locks over shared buffers.
>
You lock the mutex if needed to copy data from one thread to another; or when doing a task that depends on the data being consistent.
>
>
Ironically, this is something that fairly easily maps onto a weak memory model.
>
And is easily adapted to networked shared memory approaches as well; except that a shared-memory-system mutex is almost impractically expensive, and it may make sense to have multiple types of mutex in this case with more limited scope, say, to avoid needing to forcibly synchronize "everything".
>
>
And, it almost seems like the solution to a lot of these "problems" would be more "have everyone assume that weak consistency as the default" rather than "make every CPU and every piece of hardware obey cache coherence".
>
Or, IOW, Unless you lock the mutex, you have no idea whether the shared writable data is up-to-date. Only shared read-only data is "safe" to be accessed freely, after any initial synchronization is done.

 Are you familiar with lock and/or wait free algorithms?