4 ms·

Could you explain what you are doing? JavaScript is single threaded so I cannot see how you can implement actual concurrency control. I implemented multiversi

Could you explain what you are doing? JavaScript is single threaded so I cannot see how you can implement actual concurrency control. I implemented multiversion concurrency control in Java but I am yet to include the algorithm from the whitepaper Serializable Snapshot Isolation. https://github.com/samsquire/multiversion-concurrency-control https://github.com/samsquire/multiversion-concurrency-contro...

CMCDragonkai 4y ago
JavaScript isn't single threaded anymore. There's workers and even at the C++ extension native add-ons are exposed to libuv threading. But even in single threaded JS, asynchronous handlers can result in concurrent race conditions. That's why concurrency control is necessary. I also maintain https://github.com/MatrixAI/js-async-locks https://github.com/MatrixAI/js-async-locks repo to help control all sorts of concurrent effects.
- samsquire 4y ago
  Even from a nodejs extension and libuv perspective, Javascript has one event loop. You can create your own libuv event loops and run them on a separate pthread. If you create a pthread in your own C++ extension then you're not really talking of Javascript. Workers are not threads but they run in their own thread. Unfortunately you don't have shared memory. So you kind of have snapshot isolation by immutability. They can only communicate with postMessage. They're not threads, they do not share address space. So Javascript is single threaded. If you're getting race conditions with your multiversion concurrency control implementation, then you might need to look at how you isolate versions from one another. Write a unit test that adds numbers from 1 to 100 from 100s of concurrent transactions, you should end with 100 every time if you have no race conditions. Without parallelism, you could introduce a bulk command API and wrap all your writes and reads in a single function. The single threaded nature of Javascript will prevent race conditions if you do this - only one function can run at a time.
  - mping 4y ago
    Isn't there a SharedArrayBuffer thingy in workers now?
    - CMCDragonkai 4y ago
      Yes shared memory exists for webworkers. Furthermore JS land has different kinds of threading implementations, see threadsjs. But I'm not talking about concurrency control between threads, but between asynchronous operations.
  - CMCDragonkai 4y ago
    In our experience race conditions happen in JS regardless of its single threaded nature. It happens because of concurrent asynchronous operations that work on shared state that exists not necessarily in-memory but also in embedded databases. So most definitely concurrency control must be applied whenever there is any kind of shared state. The single threadedness doesn't matter if there are concurrent asynchronous operations.
  - CMCDragonkai 4y ago
    YMMV but when I was writing the rocksdb native binding into nodejs, I saw that any asynchronous operations setup in the C++ would be dispatched to separate threads. Didn't explore further though. It was built into the NAPI bindings.

CMCDragonkai 4y ago

JavaScript isn't single threaded anymore. There's workers and even at the C++ extension native add-ons are exposed to libuv threading. But even in single threaded JS, asynchronous handlers can result in concurrent race conditions. That's why concurrency control is necessary. I also maintain https://github.com/MatrixAI/js-async-locks https://github.com/MatrixAI/js-async-locks repo to help control all sorts of concurrent effects.

samsquire 4y ago
Even from a nodejs extension and libuv perspective, Javascript has one event loop. You can create your own libuv event loops and run them on a separate pthread. If you create a pthread in your own C++ extension then you're not really talking of Javascript. Workers are not threads but they run in their own thread. Unfortunately you don't have shared memory. So you kind of have snapshot isolation by immutability. They can only communicate with postMessage. They're not threads, they do not share address space. So Javascript is single threaded. If you're getting race conditions with your multiversion concurrency control implementation, then you might need to look at how you isolate versions from one another. Write a unit test that adds numbers from 1 to 100 from 100s of concurrent transactions, you should end with 100 every time if you have no race conditions. Without parallelism, you could introduce a bulk command API and wrap all your writes and reads in a single function. The single threaded nature of Javascript will prevent race conditions if you do this - only one function can run at a time.
- mping 4y ago
  Isn't there a SharedArrayBuffer thingy in workers now?
  - CMCDragonkai 4y ago
    Yes shared memory exists for webworkers. Furthermore JS land has different kinds of threading implementations, see threadsjs. But I'm not talking about concurrency control between threads, but between asynchronous operations.
- CMCDragonkai 4y ago
  In our experience race conditions happen in JS regardless of its single threaded nature. It happens because of concurrent asynchronous operations that work on shared state that exists not necessarily in-memory but also in embedded databases. So most definitely concurrency control must be applied whenever there is any kind of shared state. The single threadedness doesn't matter if there are concurrent asynchronous operations.
- CMCDragonkai 4y ago
  YMMV but when I was writing the rocksdb native binding into nodejs, I saw that any asynchronous operations setup in the C++ would be dispatched to separate threads. Didn't explore further though. It was built into the NAPI bindings.