[ARCHIVE]Any rookie question, so as not to clutter up the forum. Professionals, don't pass it by. Can't go anywhere without you - 5. - page 383
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
1. Not from the assumption, but from the results of the experiment, which, by the way, are confirmed by your experiment on p. 378.
2. The code on page 378 only provides atomic access. Tasks are not queued for execution. It may happen that one of the tasks will not be executed for a very long time.
The queue is created by the system. Its order is not guaranteed. It may take a long time to be executed. Is there another way in this faulty algorithm that implies a special order of access to a shared resource? You don't know when the ticks on the different charts will come, when the signals in the TS will be, etc.? What difference does it make, then, in what order the shared resource will be accessed? If the module is pending in this algorithm, then it's correct (let it wait). But not correct, in the sense of constructing the algorithm.
Read Richter. He has already described everything properly.
1. the queue is queued by the system. 2. The order in which it is executed is not guaranteed. It may take a long time to execute.
3. What, there is another way in this faulty algorithm, which implies a special order of addressing the common resource?
4. You don't know when the ticks on the different charts will come, when the signals in the TS will be, etc.?
5. What difference does it make then in which order the common resource will be accessed? If the module is pending in this algorithm, then it's correct (let it wait). But not correct, in the sense of constructing the algorithm.
6. Read Richter. He has already described the right way.
Let's go for a second round.
1. The system doesn't know which task was actually executed and which was rejected within the task itself. I.e. from the system's point of view the task is done, but since we left only one task and blocked the rest, from our point of view only one task is done. So it is our job to ensure that the tasks are regularly prioritised.
1 и 2. The queue is lined up but the order is not garnished)))) So it's not lined up, but only atomic access is provided,
3. Why not? Everything is in the hands of the programmer.
4. Everything is in the hands of the programmer.
5. If it were standing. But it does not stand. The task is not queued up, just executed or not. On the next lock (tick) it is the same, purely from the ball... it is unknown who will earn first, and the rest are out of bounds.
6. Why? As you can see, it is not always useful to read smart books. You seem to have read, but you do not understand what we are talking about. I have not read, but I understand.
Let's go over it again.
1. The system does not know which task was actually completed and which was rejected within the task itself. That is, from the system's point of view the task has been completed, but since we have only left one task and blocked the others, from our point of view only one task has been completed. So it is our job to ensure that the tasks are regularly prioritised.
1 и 2. The queue is lined up but the order is not garnished)))) So it's not lined up, but only atomic access is provided,
3. Why not? Everything is in the hands of the programmer.
4. Everything is in the hands of the programmer.
5. If I did. But it does not. The task is not queued up, it is just executed or not. On the next lock (tick), the same way, purely from the ball... it is unknown who will earn first, and the rest are behind the boron.
6. Why? As you can see, it is not always useful to read smart books. You seem to have read, but you do not understand what we are talking about. I have not read, but I understand.
That's your obsession with complex code. Instead of simplifying, you twist complicated code to break the queue.
I didn't want to read Richter for a long time either. But I read it anyway. The rules of building multi-threaded applications are simple. The main thing is to keep it simple. This is the conclusion from Richter. Otherwise, you will spend much more time on debugging than writing. By the way, I've never had to debug a multi-threaded application yet. Everything worked right away.
This is your obsession with complex code. Instead of simplifying, you twist complicated code to break the queue.
I didn't want to read Richter for a long time either. But I read it anyway. The rules of building multi-threaded applications are simple. The main thing is to keep it simple. This is the conclusion from Richter. Otherwise you will spend much more time on debugging than writing. By the way, I've never had to debug multi-threaded applications yet. Everything worked well at once.
How complicated is it? What complicated codes? It's the minimum required by the task. And your approach is noubertal. Everything that is done must work reliably, not by relying on the effect of chance.
What's Richter got to do with it? What does this have to do with multi-threaded systems? Remember the original problem that started this conversation.
Can you give me a hint? Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" ) is not compiling;
Can you give me a hint? Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" ) is not compiling;
What's the big deal? What complicated code? This is the minimum required by the task. And your approach is nouber approach. Anything done should work reliably guaranteed, not at the expense of relying on the effect of chance.
What has Richter got to do with it? What does it have to do with multithreaded systems? Remember the original problem that started this conversation.
Fine, write it however you want. I'm not gonna talk you into it. I've told you everything I can.
The original task was to make a synchronization for referring to the deposit size. The code I wrote solves it perfectly. Everything is as it should be. With minimal time of reference to the resource. All modules will be processed almost in the same order as the requests, with a few exceptions. Which is unimportant.
I highlighted it for you specifically. This is one of the rules for multi-threaded applications. If you have threads that take a long time to execute, you need to queue them up and it's important, it's a faulty algorithm. You have to redo it. You can't write it that way. You're allowed to do everything, though. Write...
1. Fine, write it however you like. I'm not going to persuade you. I have told you everything I can.
2. Initially the task was to make synchronization for referring to the deposit size.
The code I wrote solves it perfectly. Everything is as it should be. With minimal time of reference to the resource. All modules will be processed almost in the same order as the requests.
4. Specially highlighted for you. This is one of the rules for multithreaded applications. If you have threads which take a long time to execute, you need to queue them up and it's important, this is a wrong algorithm. You have to redo it. You can't write it that way. You're allowed to do everything, though. Write...
1. I had no questions for you, don't perestimate your mission.
2. Favorite word is "synchronicity"? It's a sequential parallel task.
3. Solves it, but not perfectly. Nuber - lamer method solves it.
4. Coo-coo, wake up!