flat assembler
Message board for the users of flat assembler.

Index > Windows > What happens if one proc call 4 threads ?

Author
Thread Post new topic Reply to topic
Roman



Joined: 21 Apr 2012
Posts: 1088
Roman
I have 3 threads.
I want use in all threads call MyProcA

My question what happens wrong in this case ?

Code:
;simple example
proc MyProcA
add [r15],12   ;each thread  put in r15 different mem address.
ret
endp
    
Post 16 Apr 2021, 17:53
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18471
Location: In your JS exploiting you and your system
revolution
Roman wrote:
My question what happens wrong in this case ?
Code:
add [r15],12   ;each thread  put in r15 different mem address.    
If depends upon what you mean by "wrong".

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.
Post 16 Apr 2021, 18:17
View user's profile Send private message Visit poster's website Reply with quote
Roman



Joined: 21 Apr 2012
Posts: 1088
Roman
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
Post 16 Apr 2021, 18:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18471
Location: In your JS exploiting you and your system
revolution
Roman wrote:
First i thinked.
Threads could slow down each other when call proc MyProcA
That depends upon your CPU, your OS and what other processes are running.

You will have to time it on your target system to see if there is a measurable difference.
Post 16 Apr 2021, 18:24
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 1009
Location: Belarus
DimonSoft
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.
Post 16 Apr 2021, 19:35
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18471
Location: In your JS exploiting you and your system
revolution
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
Post 16 Apr 2021, 20:03
View user's profile Send private message Visit poster's website Reply with quote
Roman



Joined: 21 Apr 2012
Posts: 1088
Roman
I planing write big code. Not simple add [r15],12
More complex code.
Post 16 Apr 2021, 20:53
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 1009
Location: Belarus
DimonSoft
revolution wrote:
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

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.
Post 16 Apr 2021, 21:13
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1768
Furs
Roman wrote:
I planing write big code. Not simple add [r15],12
More complex code.
It depends on the address of r15. Sharing the code between threads is not a problem if they refer to different memory blocks. Unless you use self-modifying code, because that writes to the code.

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.
Post 17 Apr 2021, 13:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18471
Location: In your JS exploiting you and your system
revolution
Furs wrote:
(in fact, it's a performance boost ...
Maybe. It depends upon the rest of the system.

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.
Post 17 Apr 2021, 14:01
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1768
Furs
revolution wrote:
Furs wrote:
(in fact, it's a performance boost ...
Maybe. It depends upon the rest of the system.

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.
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.
Post 18 Apr 2021, 17:45
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18471
Location: In your JS exploiting you and your system
revolution
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.
I don't know what systems Roman uses. If Roman uses NUMA systems then making a duplicate of the code into the local memory space of each CPU socket can be advantageous. But as always, it depends upon what is actually being done.

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.
Post 18 Apr 2021, 18:05
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.