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.