Yeah, there is a possible race in the using statement. The C# compiler transforms using (var obj = new Foo()) { // statements } to: var obj = new Foo(); try { // statements } finally { if (obj != null) obj.Dispose(); } The race occurs when the thread is aborted right between the obj … Read more
The race condition is, of course, between your program and some other code that operates on file (race condition always requires at least two parallel processes or threads, see this for details). That means using open() instead of exists() may really help only in two situations: You check for existence of a file that is … Read more
No, this cannot happen. Yes, there are indeed “hidden” background threads that do the work for asychronous methods, but those don’t call callbacks. All execution of javascript does happen on the same thread, synchronously, sequentially. That data event callback will always be executed asynchronously, that is, after the current script/function ran to completion. While there … Read more
I think Bjarne is wrong about this, or at least, he’s simplifying things considerably. Most modern processors are capable of writing a byte without reading a complete word first, or rather, they behave “as if” this were the case. In particular, if you have a char array[2];, and thread one only accesses array[0] and thread … Read more
INSERT INTO TABLE SELECT value_for_column1, value_for_column2, … FROM wherever WHERE your_special_condition If no rows are returned from the select (because your special condition is false) no insert happens. Using your schema from question (assuming your id column is auto_increment): insert into orders (product_id, qty) select 2, 20 where (SELECT qty_on_hand FROM products WHERE id = … Read more
All Javascript event handler scripts are handled from one master event queue system. This means that event handlers run one at a time and one runs until completion before the next one that’s ready to go starts running. As such, there are none of the typical race conditions in Javascript that one would see in … Read more
Here’s 3 different approaches: Atomic update update table set tries=tries+1 where condition=value; and it will be done atomically. Use transactions If you do need to first select the value and update it in your application, you likely need to use transactions. That means you’ll have to use InnoDB, not MyISAM tables. Your query would be … Read more
TL/DR: Transactions do not inherently prevent all race conditions. You still need locking, abort-and-retry handling, or other protective measures in all real-world database implementations. Transactions are not a secret sauce you can add to your queries to make them safe from all concurrency effects. Isolation What you’re getting at with your question is the I … Read more
While Erwin’s suggestion is possibly the simplest way to get correct behavior (so long as you retry your transaction if you get an exception with SQLSTATE of 40001), queuing applications by their nature tend to work better with requests blocking for a chance to take their turn at the queue than with the PostgreSQL implementation … Read more
Edit: I googled to check my answer: “Processing Data Queues in SQL Server with READPAST and UPDLOCK”. It’s been years since I read about and played with this solution. Original: If you use the READPAST hint, then locked rows are skipped. You’ve used ROWLOCK so you should avoid lock escalation. You also need UPDLOCK, as … Read more