Index
> Windows > What happens if one proc call 4 threads ? |
| Author |
|
|
revolution 16 Apr 2021, 18:17
Roman wrote: My question what happens wrong in this case ? You will end up with '12' added in multiple different memory addresses. If that is what you wanted then nothing wrong happened. If you wanted something else then please explain what you want to happen. |
|||
16 Apr 2021, 18:17 |
|
|
Roman 16 Apr 2021, 18:21
First i thinked.
Threads could slow down each other when call proc MyProcA Because all calls do in one address where placed MyProcA If i write in all threads the same code as in MyProcA, i get more fast code and less problems. Last edited by Roman on 16 Apr 2021, 18:25; edited 1 time in total |
|||
|
16 Apr 2021, 18:21 |
|
|
revolution 16 Apr 2021, 18:24
Roman wrote: First i thinked. You will have to time it on your target system to see if there is a measurable difference. |
|||
|
16 Apr 2021, 18:24 |
|
|
DimonSoft 16 Apr 2021, 19:35
Bad things might happen if two threads run on different cores. Since add is a read-modify-write operation, it’s quite possible for such two threads to read the same value, add the same immediate to it and then write back the same value. Which will look like if one of the threads didn’t run at all.
|
|||
|
16 Apr 2021, 19:35 |
|
|
revolution 16 Apr 2021, 20:03
DimonSoft wrote: it’s quite possible for such two threads to read the same value,.... Roman wrote: each thread put in r15 different mem address |
|||
|
16 Apr 2021, 20:03 |
|
|
Roman 16 Apr 2021, 20:53
I planing write big code. Not simple add [r15],12
More complex code. |
|||
|
16 Apr 2021, 20:53 |
|
|
DimonSoft 16 Apr 2021, 21:13
revolution wrote:
Oops, my fault. P.S. Well, still, there might be a problem with making sure different threads don’t use the same value due to some race condition. It’s still outside the piece of code given though. |
|||
|
16 Apr 2021, 21:13 |
|
|
Furs 17 Apr 2021, 13:21
Roman wrote: I planing write big code. Not simple add [r15],12 Otherwise it just reads and executes the code; reading from same memory with multiple threads is not a problem (in fact, it's a performance boost, with shared caches, so it's actually a good thing to share the code). This happens to both code and data. You only have to be careful when writes are involved. And normally you don't "write" code like I said, unless you use self-modifying code. |
|||
|
17 Apr 2021, 13:21 |
|
|
revolution 17 Apr 2021, 14:01
Furs wrote: (in fact, it's a performance boost ... Having too many threads can cause a bottleneck. And the OS has to know how to do good threading, not all OSes are good at it. And the CPU needs the cores to support concurrency. etc. etc. etc. |
|||
|
17 Apr 2021, 14:01 |
|
|
Furs 18 Apr 2021, 17:45
revolution wrote:
|
|||
|
18 Apr 2021, 17:45 |
|
|
revolution 18 Apr 2021, 18:05
Furs wrote: No I mean in comparison to duplicating the code for each thread, as he suggested. Same amount of threads, just duplicated code for no reason, because he thought reading/executing same piece of code with multiple threads is dangerous or slow or something. That is why I always go back to the one method that produces real data. Testing. Try it in different configurations and see which works best for each system of interest. If it is important enough to "make it fast" then it should also be important enough to actually test things to verify that all the rules-of-thumb are really working. It would be silly to just assume X is "faster" and never test it, only to discover later that it was all wrong, and instead Y is more performant for that task, on that system, with that OS, running Z other processes, etc. |
|||
|
18 Apr 2021, 18:05 |
|
< Last Thread | Next Thread > |
Forum Rules:
|