3 ms·

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 threa

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.

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.