6

So its in C#, and basically I'll have a position in an array for each thread to store some data. Would I Need to lock this? For example:

int[] threads = new int[12];

Each thread would access a specific position in the array for example, thread 1 will update the value in threads[0], thread 2 threads[1], etc.

Idea is to have the console print the values that are stored in the array.

Alright got so many comments. I thought I would clarify exactly what I am doing in the hopes I will learn even more. So basically the gist of it is:

The main thread kicks off 12 separate threads, each thread calls a function in the main thread to get a bunch of records from the database. The access to that method is locked but it returns about a 100 records for the thread to process by itself.

As the thread is processing the records it makes a couple of web requests and inserts into the database. Once the thread has finished processing its batch of records it calls a function again from the main thread and that function kicks off a new thread in lieu of the last one being finished.

As the threads are doing their processing I would like to output their progress in the console. Initially I locked each console output because if the same function gets called simultaneously the cursor position for each output would go all over the place. So I was thinking I would have an array that stored the counts for each value and then have a function just print it all out. Although I am starting to wonder if that would really be any different than what I currently am doing.

Improve this question
9
  • 2
    Note that this may be inefficient as hell due to false sharing. Unless you know very exactly what you’re doing it’s never a good idea to have several threads write to a common object (other than a concurrent collection). You should restructure your program flow so that it isn’t necessary. Commented Jan 20, 2013 at 1:26
  • 2
    These guys are right. This smells terrible. Remember, you should treat threads the same way you treat employees: they're expensive, so do not hire them unless you have a lot of work for them to do. Those threads are going to spend most of their time idle, waiting for the database. If you were expecting twelve letters, would you hire twelve secretaries to wait by the mailbox? Don't make threads unless they are maxing out your processor, and don't make more threads than you have processors. Commented Jan 20, 2013 at 7:18
  • 4
    Oh my - you didn't just accuse @EricLippert of not having any experience in this did you? No it really looks like you did! You might need to do a little bit of research as to who he is - really, I really would if I were you... Commented Jan 20, 2013 at 16:30
  • 2
    @AndrasZoltan: No, no, the customer always is the expert on their own system. My advice is general in nature; there may be specific situations where you want to burn the twelve million bytes that twelve threads consume, and there may be specific situations where you want to take on the pain of shared memory across worker threads. I try hard to avoid that though. Commented Jan 20, 2013 at 18:53
  • 2
    Well I'm genuinely sorry that my free and well meant advice disappointed you. Commented Jan 21, 2013 at 3:40

2 Answers 2

Reset to default
6

If each thread is accessing a value at its own index, then you should be fine as you don't have to worry about access from multiple threads simultaneously.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

This would have been my answer as well, although it's still a recipe for disaster :)
@sridawg - It's a recipe for disaster because somewhere down the line, you may access the structure from multiple threads...in which case, things are no longer threadsafe.
I suppose, unless of course I have a method that requires the thread to specify its index before accessing.
@sridawg check out my answer for a thread safety analisys in this particular situation
3

I believe that if each thread only works on a separate part of the array, all will be well. If you're going to share data (i. e. communicate it between threads) then you'll need some sort of memory barrier to avoid memory model issues.

I believe that if you spawn a bunch of threads, each of which populates its own section of the array, then wait for all of those threads to finish using Thread.Join, that that will do enough in terms of barriers for you to be safe.

MSDN documentation on Arrays says:

Public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

This implementation does not provide a synchronized (thread safe) wrapper for an Array; however, .NET Framework classes based on Array provide their own synchronized version of the collection using the SyncRoot property.

Enumerating through a collection is intrinsically not a thread-safe procedure. Even when a collection is synchronized, other threads can still modify the collection, which causes the enumerator to throw an exception. To guarantee thread safety during enumeration, you can either lock the collection during the entire enumeration or catch the exceptions resulting from changes made by other threads.

So no, they're not thread safe. Generally a collection is said to be 'not threadsafe' when concurrent accesses could fail internally, but as each thread will access different possitions, there is no concurrent access here.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.