Deutsch   English   Français   Italiano  
<100m345$38sd4$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.arch
Subject: Re: Is Parallel Programming Hard, And, If So, What Can You Do About
 It?
Date: Thu, 22 May 2025 02:45:25 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 21
Message-ID: <100m345$38sd4$1@dont-email.me>
References: <vvnds6$3gism$1@dont-email.me>
	<27492f8028a0d40eff5071e85214fc36@www.novabbs.com>
	<100gj7t$1sbnn$11@dont-email.me> <QP%WP.57065$RXsc.38723@fx36.iad>
	<100iher$2b7vi$2@dont-email.me> <jwvcyc3xd2v.fsf-monnier+comp.arch@gnu.org>
	<fcb1f88f53b1a99fae7dc50eaba94f54@www.novabbs.org>
	<i3bq2klvtcl1d47i6hp9bbbi2lud240l6e@4ax.com> <100jata$2g8o9$3@dont-email.me>
	<100ji1o$2lgt3$5@dont-email.me> <jwvecwhixg6.fsf-monnier+comp.arch@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 22 May 2025 04:45:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="08c1197d0e2fbc8c5c93da80250c8ef4";
	logging-data="3436964"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/JvNOPkc74mbtchzj5SGud"
User-Agent: Pan/0.162 (Pokrosvk)
Cancel-Lock: sha1:GgUO/iMZSqgE/IMPf9WHRLne1tc=
Bytes: 2461

On Wed, 21 May 2025 15:30:43 -0400, Stefan Monnier wrote:

> In the case of concurrency the core question is: Given a set of somewhat
> independent tasks working on some chunks of data, make sure the computed
> result is correct, e.g. design tools like mutexes, memory barriers,
> transactional memory, static analysis, reasoning principles, etc...
> whose core focus is on making sure there's no race conditions, dead
> locks, ...
> 
> In the case of parallelism, the core question instead is: given a
> program/algorithm, restructure (or even completely replace) it so as to
> divide it into somewhat independent tasks that can take advantage of
> multiple CPUs to finish the work faster.

All those issues of race conditions, deadlocks, livelocks etc apply 
equally whether the concurrency/parallelism is real (multiple physical 
CPUs) or virtual (process preemption on shared CPUs).

The difference is that different bugs in the synchronization/locking show 
up in different situations. This is why it is helpful to test your 
concurrent code in a variety of situations.