Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

To MultiThread or not to MultiThread?

Lets say a FIFO(one which is thread safe) has items being added to it ( we dont care how)

|__|  |
|  |  |
|__|  |
|  |  |
|__|  V
| d|
|__|
| c|
|__|
| b|
|__|
| a|

Now lets say the items (one by one) should be inserted to another concurrent collection .

The rate of data insertion is dynamic.

I want to do it in the fastest way. ( transfer all the elements from the Fifo to the collection).

But I'm having a conflict :

  • I could use one thread to pull out items from the Fifo and insert them into the collection. but then I wont be using cores / other threads which can help me.

  • I could use several consumer threads to take items from Fifo , but then maybe the internal locking on the Fifo (when reading), and the internal locking on the collection(when writing) will eventually reduce performance.

I mean , there will be a situation where if I have enormousness consumer threads , there will be also enormousness internal locking with the fifo / collection , plus many many context switching

How can I approach this kind of problem the right way? What is the guideline ?

like image 808
Royi Namir Avatar asked Nov 12 '22 13:11

Royi Namir


1 Answers

Multiple threads contending for the same concurrent collection will always be a bottleneck situation. The problem usually gets worse the more threads you have, but the rate of degradation depends on the locking mechanisms. I expect that the new concurrent collections in .NET 4.0 are lock-free, or at least use non-blocking locks, so they should be contention-friendly to a certain degree.

Since the question seems to be open-ended, I suggest that you simply experiment with various numbers of threads and find a balance between the fifo contention and the throughput you want to achieve.

like image 139
Tudor Avatar answered Nov 15 '22 05:11

Tudor