Comments on: A Short Guide to Mastering Thread-Safety http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/ A Blog on Parallel Programming and Concurrency by Michael Suess Fri, 12 Mar 2010 00:38:41 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Doug http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/comment-page-1/#comment-71401 Doug Mon, 21 Jul 2008 17:48:55 +0000 http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/#comment-71401 Rachna atomic data is not thread safe when you write to the atomic data because of CPU memory caching issues. Read only is safe because the cached data is always the same as what exists in memory. Even if you have atomic variables you must mark them as volatile and access them in a critical section or some other locking mechanism if you wish to update them. Rachna atomic data is not thread safe when you write to the atomic data because of CPU memory caching issues. Read only is safe because the cached data is always the same as what exists in memory. Even if you have atomic variables you must mark them as volatile and access them in a critical section or some other locking mechanism if you wish to update them.

]]> By: Michael Suess http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/comment-page-1/#comment-71141 Michael Suess Sun, 20 Jul 2008 13:13:36 +0000 http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/#comment-71141 It could be true, depending on the memory model of the particular threading-system you are using. But believe me, you probably don't want to rely on stuff as low-level as this, because its very easy to introduce mistakes there. It could be true, depending on the memory model of the particular threading-system you are using. But believe me, you probably don’t want to rely on stuff as low-level as this, because its very easy to introduce mistakes there.

]]> By: Rachna http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/comment-page-1/#comment-70606 Rachna Thu, 17 Jul 2008 04:34:06 +0000 http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/#comment-70606 I heard somewhere that if the data that is being shared by different threads is atomic, there is not need to use locks and that it will be automatically thread safe. Is this true? If it is, then please tell me what are the atomic data types available in VC++? Are atomic data types always threadsafe regardless of whether its used on 32-bit OS of 64-bit OS? I heard somewhere that if the data that is being shared by different threads is atomic, there is not need to use locks and that it will be automatically thread safe. Is this true? If it is, then please tell me what are the atomic data types available in VC++? Are atomic data types always threadsafe regardless of whether its used on 32-bit OS of 64-bit OS?

]]> By: Doug http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/comment-page-1/#comment-43161 Doug Tue, 29 Jan 2008 23:22:56 +0000 http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/#comment-43161 Or create worker threads that only read shared data and write to their own memory. Threading is much easier when threads don't talk to each other and when everything they share is read only. Or create worker threads that only read shared data and write to their own memory. Threading is much easier when threads don’t talk to each other and when everything they share is read only.

]]> By: Leniel Macaferi http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/comment-page-1/#comment-39072 Leniel Macaferi Sun, 06 Jan 2008 18:55:30 +0000 http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/#comment-39072 Hello, I'm also implementing a thread safe circular queue and as far as I went the only way I could achieve that was using locks. So I got the first option of the listing discussed in this post: put a big, fat lock right at the start of the function and unlock it at the end of the function. By the way Michael, your post is really enlightening. Leniel Macaferi Hello,

I’m also implementing a thread safe circular queue and as far as I went the only way I could achieve that was using locks.

So I got the first option of the listing discussed in this post: put a big, fat lock right at the start of the function and unlock it at the end of the function.

By the way Michael, your post is really enlightening.

Leniel Macaferi

]]> By: James Brock http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/comment-page-1/#comment-14231 James Brock Wed, 20 Jun 2007 05:54:13 +0000 http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/#comment-14231 Vivek, your thread-safe circular queue that leverages atomic increment-and-return integer operations is possible--if you only allow two threads. I tried to write a general thread-safe constant-time circular queue in C# using System.Threading.Interlocked. I thought I had it perfected, but my unit test kept failing. It took me a long time to discover the case for which it fails, and it is a case that I have no answer for: 1. Thread A enters Enqueue 2. Thread B enters Enqueue 3. Thread B exits Enqueue 4. Thread C enters Dequeue 5. Thread C exits Dequeue 6. Thread A exits Enqueue Thread C will Dequeue a nonsense value because thread A has not yet written to the underlying array, but thread B has already incremented the queue pointer. In general, your data structure will not be thread safe if you have three or more threads executing the Enqueue and Dequeue methods at different speeds. You must either abandon constant-time or use locks. Vivek, your thread-safe circular queue that leverages atomic increment-and-return integer operations is possible–if you only allow two threads. I tried to write a general thread-safe constant-time circular queue in C# using System.Threading.Interlocked. I thought I had it perfected, but my unit test kept failing. It took me a long time to discover the case for which it fails, and it is a case that I have no answer for:

1. Thread A enters Enqueue
2. Thread B enters Enqueue
3. Thread B exits Enqueue
4. Thread C enters Dequeue
5. Thread C exits Dequeue
6. Thread A exits Enqueue

Thread C will Dequeue a nonsense value because thread A has not yet written to the underlying array, but thread B has already incremented the queue pointer.

In general, your data structure will not be thread safe if you have three or more threads executing the Enqueue and Dequeue methods at different speeds. You must either abandon constant-time or use locks.

]]> By: Dieter an Mey http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/comment-page-1/#comment-74 Dieter an Mey Thu, 23 Nov 2006 16:21:13 +0000 http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/#comment-74 The problem with a lack of thread-safty is that data races may not appear during a thousand program runs, but then suddenly they do occur and cause the program to deliver wrong results or crash. A good idea to make a buggy program fail earlier is to start it on a machine which has less processors (or cores) then you are employing threads. So a single processor box may be a good platform for debugging (if your threads do not use spin-waiting, in which case the program may take a while ... ) The problem with a lack of thread-safty is that data races may not appear during a thousand program runs, but then suddenly they do occur and cause the program to deliver wrong results or crash.

A good idea to make a buggy program fail earlier is to start it on a machine which has less processors (or cores) then you are employing threads.

So a single processor box may be a good platform for debugging (if your threads do not use spin-waiting, in which case the program may take a while … )

]]> By: Michael Suess http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/comment-page-1/#comment-68 Michael Suess Wed, 08 Nov 2006 08:48:58 +0000 http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/#comment-68 @Vivek: I have not mentioned lock-free data structures, because I don't consider them safe for use (not to mention portable) yet, except when hidden from the user in a well-implemented library. I will probaby write an article about these some time later, though. @Lionell: I am not sure I understand your comment. I am not only discussing multi-processing issues, I am discussing multi-threading issues. And I do know that the problems I have outlined do happen on single-processor machines, as the scheduler is free to preempt threads at any time. Will try to make that more clear in future articles... @Vivek: I have not mentioned lock-free data structures, because I don’t consider them safe for use (not to mention portable) yet, except when hidden from the user in a well-implemented library. I will probaby write an article about these some time later, though.

@Lionell: I am not sure I understand your comment. I am not only discussing multi-processing issues, I am discussing multi-threading issues. And I do know that the problems I have outlined do happen on single-processor machines, as the scheduler is free to preempt threads at any time. Will try to make that more clear in future articles…

]]> By: Lionell Griffith http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/comment-page-1/#comment-65 Lionell Griffith Mon, 06 Nov 2006 13:41:04 +0000 http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/#comment-65 I suggest that you shift your thinking to dealing with shared resources. Its not only memory and code that's involved. Its not only parallel processing that has the problem. Preemptive multi-tasking/threading also is challenged by shared resource access even on a single core CPU. I know you think you are discussing ONLY multi-processing issues. Preemptive multi-tasking/threading has EXACTLY the same set of issue that are best dealt with by EXACTLY the same set of strategies suitable for parallel processing. Solve the shared resource contention issues for one domain and you have solved them for the other. The only necessary implementation difference between the two domains is the assignment of priorities to threads in a single CPU and assignment of threads to specific CPU's in multi-processing systems. I suspect the challenge is that few people programming today have ever had to deal with multi-priority real-time interrupt-driven data-acquisition and process-control systems. Especially ones on room sized computers with less compute power than your typical digital watch. I suggest that you shift your thinking to dealing with shared resources. Its not only memory and code that’s involved. Its not only parallel processing that has the problem. Preemptive multi-tasking/threading also is challenged by shared resource access even on a single core CPU.

I know you think you are discussing ONLY multi-processing issues. Preemptive multi-tasking/threading has EXACTLY the same set of issue that are best dealt with by EXACTLY the same set of strategies suitable for parallel processing. Solve the shared resource contention issues for one domain and you have solved them for the other.
The only necessary implementation difference between the two domains is the assignment of priorities to threads in a single CPU and assignment of threads to specific CPU’s in multi-processing systems.

I suspect the challenge is that few people programming today have ever had to deal with multi-priority real-time interrupt-driven data-acquisition and process-control systems. Especially ones on room sized computers with less compute power than your typical digital watch.

]]> By: Stefan http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/comment-page-1/#comment-62 Stefan Mon, 30 Oct 2006 07:34:10 +0000 http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/#comment-62 I wouldn't expect reading about W. Ostwald on a website like this. Good translation (as far as I can evaluate this). You got the point so far. Now I'm looking forward to the next article on that. And to which extent the word 'may' will guide you again *g*. I wouldn’t expect reading about W. Ostwald on a website like this. Good translation (as far as I can evaluate this). You got the point so far. Now I’m looking forward to the next article on that. And to which extent the word ‘may’ will guide you again *g*.

]]>