4 ms·

A mutex allows you to move potentially infinite amount of memory in one locked operation in constant time between threads. Channels imply immutable data struct

A mutex allows you to move potentially infinite amount of memory in one locked operation in constant time between threads. Channels imply immutable data structures so you're copying data into buffers and then synchronizing to send it. BEAM actually copies the data between processes (lightweight threads) heaps. I don't think it's always the case that channels are superior to mutexes in every case. I personally try write and understand lockfree algorithms and I've tried avoiding mutexes but I'm not using channels but things similar to left-right concurrency control.

gpderetta 4y ago
I'm not going to argue for mutex vs channel, but channels don't require immutable data and copying. You can forward unique_ptrs through channels and pass ownership for example, or you can forward async operations to perform remotely instead.
mgaunard 4y ago
You can hand off data with channels without any copy. That you think mutexes work in constant time is funny. How long it takes to enter a mutual exclusion section is entirely non-deterministic and unbounded.
- samsquire 4y ago
  Once the mutex is acquired, you can move any amount of data with a pointer. This is what I meant.
  - mgaunard 4y ago
    While the mutex is held, everybody else that is in contention is waiting, possibly forever. It's a terrible paradigm not suitable for any serious systems programming, especially if you have any sort of real-time requirements.
    - preseinger 4y ago
      mutexes are a primitive that guarantee access to a resource is synchronized, and only one actor is accessing it at a time this necessarily requires actors in contention to wait, possibly forever it is a fundamental paradigm that is used extensively throughout every kind of programming, even in real-time systems
      - mgaunard 4y ago
        It isn't used in real-time systems no, it's fundamentally incompatible. Check out wait-free algorithms.
        preseinger 4y ago
        synchronization requires serialized access, regardless of the nature of the consumer system (real-time or not) wait-free algorithms might use spin-locks instead of typical mutexes, but spin-locks aren't like better or faster than mutexes, they just replace syscall/io waits with hot waits

gpderetta 4y ago

I'm not going to argue for mutex vs channel, but channels don't require immutable data and copying. You can forward unique_ptrs through channels and pass ownership for example, or you can forward async operations to perform remotely instead.

mgaunard 4y ago

You can hand off data with channels without any copy. That you think mutexes work in constant time is funny. How long it takes to enter a mutual exclusion section is entirely non-deterministic and unbounded.

samsquire 4y ago
Once the mutex is acquired, you can move any amount of data with a pointer. This is what I meant.
- mgaunard 4y ago
  While the mutex is held, everybody else that is in contention is waiting, possibly forever. It's a terrible paradigm not suitable for any serious systems programming, especially if you have any sort of real-time requirements.
  - preseinger 4y ago
    mutexes are a primitive that guarantee access to a resource is synchronized, and only one actor is accessing it at a time this necessarily requires actors in contention to wait, possibly forever it is a fundamental paradigm that is used extensively throughout every kind of programming, even in real-time systems
    - mgaunard 4y ago
      It isn't used in real-time systems no, it's fundamentally incompatible. Check out wait-free algorithms.
      - preseinger 4y ago
        synchronization requires serialized access, regardless of the nature of the consumer system (real-time or not) wait-free algorithms might use spin-locks instead of typical mutexes, but spin-locks aren't like better or faster than mutexes, they just replace syscall/io waits with hot waits