Tag Info

New answers tagged

3

Apart from the points mentioned in the other answers (hard to prove that operations are independent, and programmers think serially), there is a third factor that needs to be considered: the cost of parallelization. The truth is, that thread parallelism has very significant costs associated with it: Thread creation is very expensive: To the Kernel, ...


0

REST alone is too primitive, really. You can get started with REST, but eventually, your rich application will need queries with joins and updates with transactions. Every developer attempting to add these things on their own would be error prone and inconsistent. Fortunately, there's an emerging standard called OData that does just that. It layers on ...


1

You should never ( as in never ever EVER) lock any resource while waiting for a user interaction. At some point some of your users will take off for a long weekend leaving some vital records locked. Ah but you won't let that happen because you have some clever time out/deadlock resolution scheme; then at some point this will go horribly wrong and a user ...


1

Using tokens is very common in APIs, these tokens are usually sent as a header and have a clear life cycle. Think for instance OAuth. Regardless of your programming language or framework, REST APIs are similar. I can think of several scenarios where you want to limit concurrency, two of them are: Multiple clients updating the same resources like a ...


2

Arbitrarily. The threads waiting are pushed into a container and on notify_one it will pick one and remove it. Usually the one most easily found in the structure. If you specify that the condition is fair then it's the oldest one. Often selected by keeping an ordered ring buffer that can grow as needed.



Top 50 recent answers are included