is there any situation where a data race might be useful or accommodatable?
But I think from some accepted definitions (such as Padua et al) a data race specifically is a bug, so this data interleaving if we're happy with it isn't a data race because it isn't a bug.
jerf disagrees in last sentence of other comment: https://news.ycombinator.com/item?id=23079788
https://github.com/oracle/graal/blob/4553ea71f15c9e4721565e9...
You can argue this is a bug and they shouldn't write like this, but they don't consider it a bug and they do write like this.
So your choices here tend to be: sometimes wrong, or completely useless.
Since the header on each fragment contained the total message size, I was able to pre-allocate the full size of the message upon receipt of the first fragment.
Then, as fragments arrived, I would copy their data into their respective areas of the message.
Typically, everything would arrive in order, so the message would be copied from beginning to end, piece by piece.
However, since this was Ethernet/UDP, it was possible for frames to arrive out of order.
This would result in the message being pieced together, with each fragment filling in its hole until all fragments have been received.
I guess this is a form of a data race? Or rather, a case where a data race at least wasn't detrimental.
There is no data race in your example, since the fragments are all written to different parts of memory, unless you had something else reading the message while the individual fragments were still being written.
The second thread does an unsynchronized fetch of the queue length, and then uses that fetched length as a condition in a loop that does a synchronised dequeue of a single item.
In this case, the race condition is not a problem, because the only place that data is removed is in that loop, which is a synchronised access.
So the worse case for a race here is that the length that's been read is less than the actual length, which is not a problem because that new data will just be handled the next time round.
How critical this ends up being to the program is heavily dependent on the queue data structure and how its being manipulated. But in a simple copy/linked list type situation referencing garbage data is quite likely.
A lot of traditional comp sci programs are plenty happy to teach about data synchronization primitives but completely fail to mention that most general API (posix/etc) primitives also have read/write fences implied. Those fences are as important on any processor made in the last two decades as the atomic operations themselves. As generally the implementations also provide both architectural memory barriers as well as compiler level fencing to assure the compiler isn't reordering the primitive with the code it is intended to protect. Going further, many architectures provide unfenced atomics. So, if you decide to code your own atomic_inc/swap/etc you have to also understand the memory model of the target machine before you have actually created something equivalent to what is taught in your average comp-sci department.
// Called from Thread 1.
public void AddData(Data theData) {
lock(dataQueue) {
dataQueue.Enqueue(theData);
}
}
// Worker for Thread 2.
private void ProcessingThread() {
while(true) {
int length = dataQueue.Count;
for (int i = 0; i < length; i++) {
Data curData;
lock(dataQueue) {
curData = dataQueue.Dequeue();
}
// Process data.
}
// Sleep for a short while.
}
}
So, from what I can see, in the event where the length is updated before the data is actually inserted, Thread 2 is still forced to wait until Thread 1 is finished before it can access it so it's still safe. Though if I'm wrong, please tell me. No one wants garbage data.
Also, it is possible that Count is not a member but an accessor and it might return garbage or crash if it sees some inconsistent data.
Still, both of the above can be rare occurrences. The reason that you are not seeing no particular issues is because you are basically busy waiting and polling the queue (i.e. the sleep comment); if you replaced the dataQueue.Count with just a random number generator, the code will still work. If you were doing proper signaling instead of sleeping, then your code will get stuck in case of a missed wakeup.
You are correct in that `Count` is a property, and it could be doing extra things, but according to the implementation [1] it just returns the value of a private integer. Of course, this is an implementation detail and shouldn't be relied upon, but I'm not sure how much that could be changed.
However, you are mistaken about the code continuing to work if `dataQueue.Count` were replaced with an RNG, or if it were otherwise higher than it should be. The `Dequeue` function raises an exception if called on an empty queue. This one is part of the API, not an implementation detail. An uncaught exception here would crash the thread, not just blindly carry on.
Of course, I'm no expert, and could just be talking out of my ass.
[0] https://docs.microsoft.com/en-gb/dotnet/api/system.collectio... [1] https://github.com/dotnet/runtime/blob/master/src/libraries/...
Count is implemented as a simple read currently, but that's not guaranteed to be the case in the future (that's the whole reason for having a property.
Fair enough about the rng, I'm not really a c# programmer, so I just assumed that dequeue would return a null on an empty queue.
I'm not an expert either, and certainly not a c# expert (although I kind of like the language, I haven't written a line in 7 years), so YMMV.
One practical example of using those is Hogwild, which is an implementation of stochastic gradient descent which skips synchronization on individual parameter updates, assuming that it'll converge even if some writes are lost or some reads are stale.
https://papers.nips.cc/paper/4390-hogwild-a-lock-free-approa...
In certain kinds of signals intelligence software, the primary concern is access to the current frame of data. You don’t want to miss an RF peak that lasts just a few nanoseconds. It can be preferable to have half the the frame overwritten mid-processing every few million iterations than to slow down each iteration and force a lower overall refresh rate.
That's a data race, the result will vary between executions because the row order will be different depending on how fast the various servers respond, but acknowledging that the order is not-well defined or guaranteed makes this data race accomodatable and even useful, since that gives a performance benefit compared to any solution that needs to ensure a specific order of these rows.