[HN Gopher] Concurrent Programming with Harmony
       ___________________________________________________________________
        
       Concurrent Programming with Harmony
        
       Author : todsacerdoti
       Score  : 47 points
       Date   : 2025-07-11 01:22 UTC (3 days ago)
        
 (HTM) web link (harmony.cs.cornell.edu)
 (TXT) w3m dump (harmony.cs.cornell.edu)
        
       | ygritte wrote:
       | These docs fail to separate concurrency from parallelism. I would
       | have expected more from something that comes out of a university.
        
         | maxmcd wrote:
         | How would a distinction between concurrency and parallelism
         | benefit the modeling of program logic?
         | 
         | The programming language incorporates thread+locking
         | mechanisms.
        
           | Kranar wrote:
           | Parallelism introduces additional hazards such as data races,
           | which are not present in concurrent code that lacks
           | parallelism.
        
             | seanw444 wrote:
             | I'm of the opinion that we chose the wrong term for
             | concurrency. Concurrency means multiple things going on
             | simultaneously, which is not what's happening with our
             | version of it. Only one thing is happening at any given
             | time, but the tasks are being _multiplexed_ on a shared
             | resource. Parallelism = concurrency,  "concurrency" =
             | multiplexing.
             | 
             | Maybe there's a more appropriate term than multiplexing,
             | but I think that's certainly better than concurrency at
             | describing it.
        
               | Kranar wrote:
               | Yes that's true the terms are confusing but nevertheless
               | it's important. For example having read through some of
               | this book it's still not clear if this book involves
               | parallelism, especially since the book compares itself to
               | Python, which does not involve parallelism without
               | running C extensions.
        
             | Jtsummers wrote:
             | Data races and other race conditions are still present in
             | concurrent systems without parallelism (of the actually
             | executing at the same time sense, like with multiple
             | cores). If they weren't, we wouldn't need most uses of
             | mutexes and semaphores on single core processors. As the
             | book gets into, concurrency is about multiple tasks that
             | are arbitrarily interleaved with each other. That
             | interleaving is why you can have data races and other
             | errors even in a single core system.
        
               | Kranar wrote:
               | Data races are not possible on a single core system.
        
               | convolvatron wrote:
               | they are entirely possible assuming preemptive scheduling
        
               | Kranar wrote:
               | Yes that's true and I was wrong to say otherwise. A data
               | race can happen with preemptive multithreading on data
               | whose size exceeds what the platform guarantees to access
               | atomically, typically the word size.
               | 
               | A more accurate statement would be that parallelism
               | introduces additional possibilities for data races than
               | those possible from concurrent execution (without
               | parallelism).
        
         | convolvatron wrote:
         | Robert van Renesse is a hugely respected distributed systems
         | researcher with decades of influential publications, and is
         | highly respected as a mentor in the community.
         | 
         | I'm sorry that you feel his contributions are meaningless
         | because he hasn't caught up with the way that devops people
         | talk about these things.
        
       ___________________________________________________________________
       (page generated 2025-07-14 23:01 UTC)