Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Don Y Newsgroups: sci.electronics.design Subject: Serial, concurrent, parallel Date: Tue, 14 Jan 2025 11:10:06 -0700 Organization: A noiseless patient Spider Lines: 114 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 14 Jan 2025 19:10:12 +0100 (CET) Injection-Info: dont-email.me; posting-host="c0467f359869fa40c2874317f9c8419b"; logging-data="2659405"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19o6le74VsWw7cHOe3BFA8p" User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cancel-Lock: sha1:32FIHlLvIUEq1HHyfv1+gazy0io= Content-Language: en-US Bytes: 6323 I am surprised (disturbed?) at the problems people seem to have sorting these things out in their thought processes. I don't *believe* people think strictly "serially" but I am beginning to question that belief as I witness smart/capable people stuck in that mindset! I've been finding problems with their implementations that would not be present if they TRULY "thought in parallel". Things that should be obvious seem to slip right past them. This came to a head when I asked a colleague to explain multitasking: "Well, FIRST, the processor does... and THEN..." "Ah, 'THEN'! So, you are thinking about multitasking as the SERIALIZATION of multiple tasks instead of the CONCURRENT execution of them! So, when your code is run in true parallel form (multiple cores, multiple processors), all of those hidden assumptions that you've baked into your design fall apart because they are no longer implicitly serialized! "THIS is what your algorithm does (see Petri net X) and this is what you THINK it does (see Petri net Y). See the differences? The *hardware* does! And THIS is where the bug manifests..." I tackled the problem with folks failing to understand how an IPC/RPC/RMI can fail *in* the (apparent) function invocation -- by sugarizing the syntax to make RMI's more obvious. One source of problems (largely) gone. But, there still seems to be a problem wrapping people's heads around the fact that something is truly executing in parallel -- and, likely on some other processor (with all that entails). I.e., unlike a multicore/SMP implementation where the other processor is there, beside you (so, "available" as much as 'YOUR' processor is), an RMI can actually get started and then fail "later" (e.g., if the remote node is powered down, disconnected, etc.). So, you can't rely on the fact that the invocation succeeded to be indicative of the actual method running to completion. This is particularly important for asynchronous actions where your thread doesn't virtually migrate to the remote node but, effectively, forks, expecting a later join. TL;DR. I need a mental model that is easy for folks to consult to "remind/reinforce" this true parallelism. I'm hoping to discuss it at an upcoming off-site where they can feed off each other's understanding of it. Perhaps "inspired" by the travel issue, I'm thinking along the lines of "taking a trip" and the steps involved: Contact airline to arrange travel Airline (phone/www) may not be available at that time. Or, you may lose the connection (voice/data) during the transaction. How to recover: Spin? Reschedule? Spawn a separate task to handle that contact (i.e., ask your secretary to do it WHILE you do something else) Book hotel No vacancies. Find another? Pack clothing/supplies Some items may need to be washed/purchased. Spin? Reschedule? Spawn a task to handle those dependencies (i.e., have spouse run out and pick up those few items needed) Go to airport Family car? Taxi? Uber? Check luggage Board flight Fly Arrive destination Deplane Collect luggage ... I.e., some of these things are truly serial (can't "fly" until after you have boarded the flight). Others can be handled concurrently. And, some are truly parallel. Order is flexible WITHIN a set of dependency constraints (e.g., you can easily imagine packing BEFORE having your travel reservations. Or, while "on hold" with the travel agent.) NEEDLESSLY serializing them just means it will take you longer (wall time) to get them done. At the extreme, you may miss your intended arrival time/date! *But*, the more important issue that hides in these dependencies is that they can abend and you (the traveler) will have to catch those "exceptions" and handle them if you really want to ensure your travel! E.g., your secretary could tell you (after you'd "delegated" that task) that there are no flights available on your desired travel days. YOU, then, have to decide on a new strategy/timetable. Or, the flight could get canceled AFTER you have a confirmed reservation. Your luggage might not arrive WITH your flight. The hotel might have double-booked your room. Etc. So, WHILE you are proceeding on what you think is a successful path to your goal, exceptions can be thrown ASYNCHRONOUSLY that require your attention. In some cases, you can ignore them until they manifest as hard failures (i.e., you get to the airport and THEN realize the flight was canceled and the SMS that you ignored likely was a notification of this event!) This is complex (in writing) but trivial -- and relatable -- in a discussion. I *think* it draws attention to the fact that things are actually happening in parallel despite the fact that you might WANT to think of this as a SERIES of steps towards a goal. You certainly wouldn't describe it as "I called the airline AND THEN..." because you would know that many things were (or could) be happening at literally the same time. Can anyone suggest a simpler "real world" problem to promote these "situations/scenarios"?