New answers tagged multithreading
4
There are a couple of issues with destructors, firstly is the issue with closing pipes on Linux/Unix as discussed here (though the pipe is actually no longer necessary once we fix the second issue). Secondly the functools.partial method appears to capture a reference to self which causes the wrapper object to not be destructed when expected, I have fixed ...
2
Overall I think the code is pretty good and your use of the more modern features of C++ looks OK.
Still there are some things that could be improved. In no particular order I offer the following suggestions:
The idea of a scoped_thread is good (also discussed in Effective
Modern C++ item 37). Even if you want to implement your own
std::thread replacement (...
2
You probably won't be able to do much to speed up get_hashtag_posts since that's an API call; if you try to hammer it by running multiple queries in parallel, a well-designed API will interpret that as a DDOS attack and rate-limit you.
As far as your code goes, though, you should be using a set instead of a list, since sets are optimized for the exact thing ...
1
You definitely should remove all Console.WriteLine operations that are executed during the measuring. You want to measure pure excecution time.
Also thread creation/management costs time i.e. overhead. When using Thread (executing PrintLoopWithThread) you started the Stopwatch BEFORE you created the threads, which is correct, because you want to include ...
1
The Console uses synchronization:
I/O operations that use these streams are synchronized, which means that multiple threads can read from, or write to, the streams.
This synchronization ensures that all sentences are printed and nothing gets lost due to a data race.
However, synchronization kills multithreading, because the threads will stop at the ...
1
Ensure the mutex is locked when changing should_terminate_m
In the destructor, you should hold the mutex locked while changing should_terminate_m. It may work as it is in this particular case, but in general, if you hold a mutex while accessing a variable anywhere in the code (it's held in thread_loop() while reading it), you should hold the mutex ...
2
You have a lot of interesting things going on in your code. There are many ways to solve your problem, here is an approach utilizing an ActionBlock. I used .NET Core 3.1 to build the sample, but ActionBlock is available in the System.Threading.Tasks.Dataflow NuGet Package if it isn't included in your framework by default.
1) Change your entry point from ...
2
Your code has a bug. I can reproduce it fairly consistently by changing your run method to:
@Override
public void run() {
try {
for(int i=0;i<100;i++) {
uniSexBathroom.occupy(person);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
Notice, that I've increased the number of times that each ...
2
Overview
Normally a ThreadPool has a fixed number of threads. With a variable amount of work that is to be completed by the threads. You have gone the other way. You have as many threads as there is work. So your pool is not really a pool of workers it is more of a thread maintainer than a thread pool.
Threads are relatively expensive to create. The amount ...
Top 50 recent answers are included
