3 ms·
Now that we are on the subject, what is one sane way to drastically reduce the need for locks and semaphores? Use actors like Erlang does. A class with a thread
by cmccabe 13y ago
Now that we are on the subject, what is one sane way to drastically reduce the need for locks and semaphores? Use actors like Erlang does. A class with a thread and a queue attached to it. Then avoid sharing data instead send messages. You'll be hit with a serious performance issue because of memory copying, because well, there is no free lunch.
In Golang, you can avoid the serious performance issue by sending a pointer over a channel and treating that as a transfer of ownership of the data.
- rdtsc 13y agoYap. But it breaks isolation. Some places need that. There is no free lunch again. Otherwise semantically it is accessing the same data from multiple concurrency contexts. Once that concurrency grows it becomes very hard to reason about who and when changed what if you get a crash. Setting write watch-points in gdb is one way I found to do it in C++ for example.
- cmccabe 13y agoYou can always pass around pointers to immutable data structures which only implement read interfaces.
- rdtsc 13y agoExactly. Or maybe copy-on-duplicate-access detection. So keep a single copy on heap but when accessed first time by second context/thread then make a copy of it. Azul's Java GC plays some of these games with read barriers. They detect reads to certain pointers and set callbacks to run custom code when they happen.