[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 382
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
A big round of applause! About the code from page 378. Even if the terminal registers the queue order, it cannot know in which case the function was executed and in which case it was rejected.
So what? Why would he need to know that? Atomic access is assured. That's enough. Handle the rest yourself. What task are you talking about? It's all abstract.
Atomic access is not enough. There is no guarantee of consistent execution of tasks, some task may be left behind. Your code and logs show that tasks are performed haphazardly, not sequentially.
...Handle the rest yourself...
That's what I'm saying, you have to do it yourself, just providing atomic access isn't enough.
...That's enough. Handle the rest yourself....
Vadim, you are amazingly contradicting yourself. First you write that enough is enough. Then you realise (or guess) that something else needs to be done.
has been created, can it be further used in a traditional way -
Profit_pomnim=365; Bumbara=Profit_pomnim; or it should be called only through special functions? GlobalVariableSet("Profit_pomnim", 365);
Good day! Please write, after creation of a global variable GlobalVariableSet("Profit_pomnim", Itogo_Profit);
can it be further used in a traditional way -
Profit_pomnim=365; Bumbara=Profit_pomnim; or it should be addressed only through special functions?
Bumbara=Profit_pomnim - you can't do this, there is no Profit_pomnim variable. But there is a global variable Profit_pomnim.
This is how it should be: Bumbara=GlobalVariableGet("Profit_pomnim");
Atomic access is not enough. There is no guarantee of consistent execution of tasks, some task may be left behind. Your code and logs show that tasks are executed haphazardly, not sequentially.
I suspect that you are fixated on a special order of addressing a resource. This is the wrong approach for organising the algorithm. Write it in such a way that it doesn't matter.
That's what I'm saying, you have to take measures yourself, but providing atomic access is not enough.
Vadim, you are amazingly contradicting yourself. At first you write that it is enough. Then it turns out that you understand (or guess) that something else needs to be done.
There is no contradiction. Above replied.
====================
As for being complicated, I remember how you wrote a function with a complex algorithm for calculating the number of days in a month. I still smile when I recall it.
Dmitry, there is no need to overcomplicate it. If you have constants, you do not have to calculate them. You just have to declare them.
The same refers to multi-threading. If you do not need it, you must not use it. The special order of addressing a resource implies single-threaded execution.
One more thing about system regulation. If several threads are created - yes, the system will regulate. But if someone from the side has entered these threads, then you have to think about everything yourself, there will be no miracle from the system.
Zhunko:
1. I don't understand... What do you mean...? What guarantee?
2. You call yourself a programmer.
3. Write so that it's guaranteed.
4. How can a task "get behind the bot"? What did you write in there that it's not being executed?
5. I suspect you're fixated on the special order in which the resource is accessed. This is the wrong approach for organising the algorithm. Write it in a way that doesn't matter.
6. In my practice this has never been required. You can always avoid this approach. Keep it simple. It will work more reliably.There's no contradiction. I answered above.
====================
7. As for being complicated, I remember how you wrote a function with a complex algorithm for calculating the number of days in a month. I still smile when I remember it.
8. Dmitry, there is no need to complicate things. If you have constants, you don't have to calculate them. It is enough to declare them.
9. The same refers to multi-threading. If you don't need it, don't use it.
1. Sorry!
2. Where, when, where? What's that got to do with it now?
3. I'm writing in a way that's guaranteed.
4. Any of those that are atomically accessible.
5. No. And not looped, but taking steps to ensure that all tasks are carried out in order.
6. Don't blather on. The data exchange function between terminals from your library requires this, not just atomic access.
7. What function is that? Tell me more. This one? What's so funny? Maybe you just didn't understand something. If that function, it was a sporting interest and nothing more. By the way, it is a very complex task and the most optimal algorithm for this task (of those known) is also quite tricky. So your sarcasm is unfortunate.
8. Or maybe you should get a job in a kindergarten as a nurse? The level of preaching is the same, suitable. Maybe in the previous paragraph hint that I kind of do not know how to translate time in seconds to hours minutes, etc. by functions emkulya?
9. Problems with memory, or awareness of reality? Remember what the discussion is about - how to turn a parallel execution of tasks into a sequential one.
9. Problems with memory, or with awareness of reality? Remember what the conversation is about - how to turn parallel execution of tasks into sequential execution.
Your assumption that synchronisation is out of sync is where it started:
Vadim, have you tried applying it? It doesn't sync up a damn thing. I've been playing with it recently. You have to build the queue yourself. Unfortunately, it only reduces the code by three lines. Or maybe I don't understand it.
Here's the code where the synchronization works. Atomic access to the resource is provided. The rest is your fiddling with bringing threads into a single thread. I've suggested you to revise the wrong algorithm. There is only one correct solution to such a task - combine all the code into a single thread. Then the resource will be called in order without synchronization. The code's running time will be the same as in multi-thread execution. Keep it simple.
1. Your assumption that the synchronisation is not working started with you:
Here is some code where synchronization works. Atomic access to the resource is provided. The rest is your fiddling with thread convergence. Suggested you revise the wrong algorithm. The only correct solution to such a task is to merge everything into a single thread. Then the resource will be called in order without synchronization. The code's running time will be the same as in multi-threaded execution. Simplify it.
1. Not from an assumption, but from the results of an experiment, which, by the way, are also confirmed by your experiment on p. 378. 378.
2. The code on page 378 only provides atomic access. There is no queue for executing tasks. It may happen that one of the tasks takes a very long time to be executed.