3 ms·
That's the limitation of Erlang, right there. They get in line, creating a bottleneck. You could have 10,000 Erlang processes, but they all wait in line for thi
by johndonsp 14y ago
That's the limitation of Erlang, right there. They get in line, creating a bottleneck. You could have 10,000 Erlang processes, but they all wait in line for this one process to service them.
If you use transactional memory with threads and mutable state, then all your booking processes can access the board state in parallel with ACI properties. Obviously, parallelism is still limited, as it always it, but as long as your booking processes are accessing different parts of the seat data structure, they can run in parallel. If they try to access the same part of the structure at the same time, all but one will be rolled back, but that one still gets through. Hopefully, they access different parts of the structure and sail through.
Your suggested Erlang program has no parallelism in it at all (for the isolated part of the seat booking of course), and will not scale to 2 cores, let alone the 64 cores I have in my machines at work.
- silentbicycle 14y agoErlang is not about parallelism, it's about fault tolerance. It's about "making reliable distributed systems in the presence of software errors" (as Armstrong's thesis is titled). How will your STM example behave if the computer managing the transactions suddenly has a massive hardware failure?
- johndonsp 14y agoI completely agree with you about fault-tolerance. However Erlang, CSP, actors and message passing are heralded as the key to parallelism. The Erlang book still promises n-times speedup for n-cores, with not enough of a caveat.
- silentbicycle 14y agoI'm not familiar with the plane scheduling problem, there is probably room to parallelize it further. I suspect people are far less likely to book seats on both sides of the aisle(s) at the same time, for example. Knowing more about those things, airline regulations, and so on will probably present other opportunities.
- mononcqc 14y agoYou could do as jlouis suggested and have each plane or flight manage its own seats/places. The state of different flights or planes isn't necessarily related and can be handled differently, giving you a smaller isolated unit than "everything at once". This gives place to parallelism as soon as you have more than one plane to contend resources for in your concurrent model, which is most likely the case in the real world. If you have only one plane, then you likely won't need to scale.