multithreading

问题 I know in a multithread environment doing this is not safe: if (some_var > 0) { // Do something. } Because when comparing, there might be another thread changing the value. What if some_var is a counter. That is, it can only increment, never decreases. Then is following operation thread safe? if(some_counter >0) { // Do something. } Also does it make difference if some_counter is either byte, or int32, int64? 回答1: What if some_var is a counter. That is, it can only increment, never decreases.

问题 I have two nested loops: !$omp parallel !$omp do do i=1,4 ... !$omp parallel !$omp do do j=1,4 call job(i,j) My computer can run four threads in parallel. For the outer loop such four threads are created. The first three finish quickly since for i=4 , the job is four times more expensive. Now I expect that in the inner parallel region, new threads share the work. But this doesn't happen: The CPU load stays at 1/4, just as if the 4th thread works serially on the inner loop. How can I allocate

问题 I'm running a couple of threads in parallel. And I want to measure the time it takes to execute one thread and the time it takes to execute the whole program. I'm using VC++, on Windows 7. I tried to measure it while debugging but then I saw this question: https://stackoverflow.com/questions/38971267/improving-performance-using-parallelism-in-c?noredirect=1#comment65299718_38971267 and in the answer given by Schnien it says: Debugging of multiple threads is somehow "special" - when your

问题 Based on the Python documentation, daemon threads are threads that die once the main thread dies. This seems to be the complete opposite behavior of daemon processes which involve creating a child process and terminating the parent process in order to have init take over the child process (aka killing the parent process does NOT kill the child process). So why do daemon threads die when the parent dies, is this a misnomer? I would think that "daemon" threads would keep running after the main

问题 Based on the Python documentation, daemon threads are threads that die once the main thread dies. This seems to be the complete opposite behavior of daemon processes which involve creating a child process and terminating the parent process in order to have init take over the child process (aka killing the parent process does NOT kill the child process). So why do daemon threads die when the parent dies, is this a misnomer? I would think that "daemon" threads would keep running after the main

问题 In the following code, how could one ensure that ptr not incremented until after *ptr has been loaded/assigned/"extracted"? extern int arr[some_constexpr]; // assume pre-populated extern int* ptr; // assume points to non-atomic arr int a = *ptr; // want "memory barrier/fence" here ++ptr; Would an atomic pointer ensure the correct ordering/sequencing? #include <atomic> extern int arr[some_constexpr]; extern std::atomic<int*> ptr; int a = *(ptr.load()); // implicit "memory barrier" achieved

问题 I am rather inexperienced with Java and multi-threading so maybe you guys can help. I am having trouble printing out a series of numbers and letters in a TextArea box when I multi-thread. This is my code: public class MultiThread extends Application { static TextArea outputArea = new TextArea(); @Override public void start(Stage primaryStage) throws Exception { outputArea.setWrapText(true); Runnable printA = new PrintChar('a', 100); Runnable printB = new PrintChar('b', 100); Runnable print100

问题 I'm writing a script that will use python's multiprocessing and threading module. For your understanding, I spawn as much processes as cores are available and inside each process I start e.g. 25 threads. Each thread consumes from an input_queue and produces to an output_queue . For the queue object I use multiprocessing.Queue . After my first tests I got a deadlock because the the thread responsible to feed and flush the Queue was hanging. After a while I found that I can use Queue().cancel

问题 I'm writing a script that will use python's multiprocessing and threading module. For your understanding, I spawn as much processes as cores are available and inside each process I start e.g. 25 threads. Each thread consumes from an input_queue and produces to an output_queue . For the queue object I use multiprocessing.Queue . After my first tests I got a deadlock because the the thread responsible to feed and flush the Queue was hanging. After a while I found that I can use Queue().cancel

问题 It is said volatile is needed for signal handler, e.g., volatile int flag = 1; // volatile is needed here? void run() { while(flag) { /* do someting... */ } } void signal_handler(int sig) { flag = 0; } int main() { signal(SIGINT, sig_handler); run(); // ... } It is said volatile is often not used in multithreading. But how about the similar case like above in multithreading: int flag = 1; // is volatile needed here? void thread_function() { while(flag) { /* do someting... */ } } int main() {