Mar-18-2022, 09:39 AM
I see nothing here that even hints that there is an order of executing the threads. Get this, and internalize it, and own it: Unless you provide an external means to determine how threads execute, they are guaranteed to execute in random order. They are not even required to execute in the same order on two different executions of the same program. Since you did nothing to force p2 to wait until p1 completed, it might be just as legitimate to see any of the following come out:
And here's an important guideline: if you have to put a sleep() call in, your code is WRONG. Not just a little bit wrong. COMPLETELY wrong. When I would get multithreaded code from a client, the first thing I did was look for sleep() calls. If I found any, I would double my price to solve the problem, because it meant the entire algorithm design was flawed and I would first have to reverse-engineer it to determine what it was trying to do, then fix it. sleep() calls merely exacerbate any sequencing problems and do not accomplish anything predictable. It is delusional to think that they will do anything meaningful. While there are times they are required, they do not in any way guarantee sequencing. For example, if I need a thread to sample data once a second, I can put sleep(1000) in the loop, and this means that approximately once a second (with emphasis on "approximately") the thread will run. But there is no guarantee. It might be ten seconds before it runs. But it will not be less than one second. In my course, I spend a couple hours discussing the problems of multithreading. It is not a simple subject, and your "intuitions" are always wrong until you study how threads really work.
Hint: on most operating systems, sleep() is quantized. For example, on Windows, sleep(1) through sleep(15) mean the same thing: sleep(15). Which says that it will be at least 15 milliseconds before the thread runs. But this means there is no order guarantee. Maybe the first thread runs first, and maybe the second thread runs first. So you have to understand what is really going on before you start (as I call it) "sprinkling sleep calls like fairy dust into your code in the hope that it will fly". It's a bit like saying "My computer doesn't work, so I'm going to start hitting each chip with a hammer until it does". Using sleep() is the mark of a complete newbie, and I can tell you from decades of experience, it is always, without exception, the wrong thing to do. Until you understand how threads work in your OS, you are basically clueless. And I don't have the motivation to type in a two-hour lecture.
Hello hi ===== hi Hello ===== Hehelilo ===== Hellhio ===== hHiello =====Unless you make a special effort, threads run in any order, at any time, and may be preempted in any way whatsoever. Anything you see that suggests there is an order is delusional. It is how the threads ran for this execution. Next execution may be different. This is what makes multiprocessing such fun. The nondeterminism is intrinsic to the problem.
And here's an important guideline: if you have to put a sleep() call in, your code is WRONG. Not just a little bit wrong. COMPLETELY wrong. When I would get multithreaded code from a client, the first thing I did was look for sleep() calls. If I found any, I would double my price to solve the problem, because it meant the entire algorithm design was flawed and I would first have to reverse-engineer it to determine what it was trying to do, then fix it. sleep() calls merely exacerbate any sequencing problems and do not accomplish anything predictable. It is delusional to think that they will do anything meaningful. While there are times they are required, they do not in any way guarantee sequencing. For example, if I need a thread to sample data once a second, I can put sleep(1000) in the loop, and this means that approximately once a second (with emphasis on "approximately") the thread will run. But there is no guarantee. It might be ten seconds before it runs. But it will not be less than one second. In my course, I spend a couple hours discussing the problems of multithreading. It is not a simple subject, and your "intuitions" are always wrong until you study how threads really work.
Hint: on most operating systems, sleep() is quantized. For example, on Windows, sleep(1) through sleep(15) mean the same thing: sleep(15). Which says that it will be at least 15 milliseconds before the thread runs. But this means there is no order guarantee. Maybe the first thread runs first, and maybe the second thread runs first. So you have to understand what is really going on before you start (as I call it) "sprinkling sleep calls like fairy dust into your code in the hope that it will fly". It's a bit like saying "My computer doesn't work, so I'm going to start hitting each chip with a hammer until it does". Using sleep() is the mark of a complete newbie, and I can tell you from decades of experience, it is always, without exception, the wrong thing to do. Until you understand how threads work in your OS, you are basically clueless. And I don't have the motivation to type in a two-hour lecture.
