3 ms·

Some databases are able to provide serializability while not grabbing a global synchronous lock for all transactions. Even if the execution must appear synchro

by emmab 9y ago

Some databases are able to provide serializability while not grabbing a global synchronous lock for all transactions. Even if the execution must appear synchronous to an observer, it's sometimes possible to do some async work. That could be because it's performing an operation which is atomic to the JS application (e.g. a sort operation can be implemented with parallelism because the JS app is paused the whole time it's running). Or, the JS interpreter could perform static analysis on control flow and determine that two or more computations do not depend on eachother for a period of execution.

he0001 9y ago
Of course the they can, but that's not the thing here and it's about JS. The "lock" here is the event loop, and that's the issue. I don't understand the part where the database is doing work is in any way related to what the JS app is doing. Even if you are running on the same machine, they are bound to have different runtime scopes and not related on how they execute.
- emmab 9y ago
  The event loop doesn't strictly have to act as a global lock. It just has to appear to act as a global lock to any observer.
  - he0001 9y ago
    Can you describe where this would be the case?
    - emmab 9y ago
      That could be because it's performing an operation which is atomic to the JS application (e.g. a sort operation can be implemented with parallelism because the JS app is paused the whole time it's running). Or, the JS interpreter could perform static analysis on control flow and determine that two or more computations do not depend on eachother for a period of execution, and can thus be performed in parallel. Or, as long as the JS isn't performing IO, the execution environment can use optimistic concurrency[1] and back out the changes if the codepaths did have interdependency or tried to perform IO. [1] https://en.wikipedia.org/wiki/Optimistic_concurrency_control https://en.wikipedia.org/wiki/Optimistic_concurrency_control
      - he0001 9y ago
        But that is still not asynchronous in relation to the program flow. Running other unrelated tasks is not asynchronous like that, it's concurrent execution. Asynchronous would mean that something that share context, time or execution, is run out of order in relation to each other. And even if it's using optimistic concurrent execution, in relation to program flow it's still synchronous. The event loop is still synchronizing program flow, even if it does optimistic concurrency control. Concurrent doesn't mean "out of order", it means "at the same time".

by emmab 9y ago

he0001 9y ago

Of course the they can, but that's not the thing here and it's about JS. The "lock" here is the event loop, and that's the issue. I don't understand the part where the database is doing work is in any way related to what the JS app is doing. Even if you are running on the same machine, they are bound to have different runtime scopes and not related on how they execute.

emmab 9y ago
The event loop doesn't strictly have to act as a global lock. It just has to appear to act as a global lock to any observer.
- he0001 9y ago
  Can you describe where this would be the case?
  - emmab 9y ago
    That could be because it's performing an operation which is atomic to the JS application (e.g. a sort operation can be implemented with parallelism because the JS app is paused the whole time it's running). Or, the JS interpreter could perform static analysis on control flow and determine that two or more computations do not depend on eachother for a period of execution, and can thus be performed in parallel. Or, as long as the JS isn't performing IO, the execution environment can use optimistic concurrency[1] and back out the changes if the codepaths did have interdependency or tried to perform IO. [1] https://en.wikipedia.org/wiki/Optimistic_concurrency_control https://en.wikipedia.org/wiki/Optimistic_concurrency_control
    - he0001 9y ago
      But that is still not asynchronous in relation to the program flow. Running other unrelated tasks is not asynchronous like that, it's concurrent execution. Asynchronous would mean that something that share context, time or execution, is run out of order in relation to each other. And even if it's using optimistic concurrent execution, in relation to program flow it's still synchronous. The event loop is still synchronizing program flow, even if it does optimistic concurrency control. Concurrent doesn't mean "out of order", it means "at the same time".