views:

481

answers:

7

On a quad-core machine, I am considering the parallelization of C#/.NET algorithm which involves having multiple threads reading the small int[] array concurrently. So far, it seems to be working rather well, but I am not sure where it is specified that concurrent reads on an array are thread-safe in .NET. Any pointers?

Then, I am also wondering if this approach is really efficient? Are there situations where you are better off actually duplicating the input data for each thread, so that there isn't any concurrent read, and each array (maybe?) gets the opportunity to be cached near affinity CPU?

Any thoughts on the best practices in respect of multicore CPUs?

+10  A: 

I don't think there's a problem with concurrent reads. It could be problematic if there are concurrent writes, though.

Immutable data is inherently thread-safe.

Martinho Fernandes
I wholeheartedly agree with you that immutable data is thread-safe. Sometimes however, it is hard to determine if data won't change. For instance, an apparent read operation (or let say 'query method') on an object can cause a write internally. You always have to be on the lookout for that. With arrays however: reading the array will definitely not change it.
Steven
@Steven agree that you can't always tell if something is immutable. But I think your example is simply bad design. I believe that immutable data (especially when shared) should be explicitly designed as such.
Martinho Fernandes
@Marthinho: You have no idea how much bad design I witnessed in my carrier :-) It made me a compulsive, suspicious developer. I trust nobody, not even myself :-) Nevertheless, I agree with all you've said here.
Steven
+1  A: 

There is no reason not read the content of an array concurrently assuming that is content will never change. There is no concurrency issue hence no need to copy.

I doubt there is much you can do to make it faster either.

AnthonyWJones
+1  A: 

It shouldn't bother you. Concurrent read is not a problem. Any number of threads can read the same memory at the same time.

sharptooth
A: 

Thread-safety is only an issue when you update data. If you have multiple concurrent threads updating the array you will have to wrap the updates (and reads if the updates are not atomic) in a synchronisation mechanism. For a read-only data structure the concurrency is a non-issue.

ConcernedOfTunbridgeWells
Not necessarily. In an array, no it isn't an issue, but in collections, reads may not be threadsafe at all.
Spence
+3  A: 

In your case, concurrent reads over your array will be thread safe.

As for your algorithms effectiveness, depending on the size of your array, if it will fit in the cache then you may see excellent performance gains, as the multicores effectively "fight" for cache in the CPU. If they are fighting to fill the cache with the same information, they will share meaning more cache hits and better performance.

Assuming that your array fits into the cache...

Spence
+1  A: 

If .NET performance and parallelism are at stake, I'd recommend to try writing this specific algorithm in F#. F# compiler will generate .NET code that has 2-6 better performance.

Rinat Abdullin
A: 

The assignment operator is not thread safe.

This means if your threads are only reading the array - if the array was initialized at programme start and does not change - then you are safe.

However, if a writer exists who writes new values, you are vulnerable to a race condition.

The basic issue is this; a reader begins to read an integer. The value is loaded from memory into a register. At this point, the reader swaps out. The writer then updates the value in memory. The reader then swaps back in and acts on the value he loaded - which is no longer correct.

This means that things like if() do not work reliably. For example,

if( int_array[5] == 10 ) { }

May trigger when the in-memory value of int_array[5] is no longer 10.

I believe in C#, you should have access to the Interlocked*() function calls, such as InterlockedCompareAndSwap(). These will permit you to easily achieve thread safety in this case.

Blank Xavier