flat assembler
Message board for the users of flat assembler.
Index
> Tutorials and Examples > A small Win32 game (2 threads) example |
Author |
|
AsmGuru62 29 Jan 2013, 18:16
I wrote this testing my FASM Writer during Christmas time in 2011.
Read the ReadMe.Txt.
|
|||||||||||
29 Jan 2013, 18:16 |
|
AsmGuru62 15 Feb 2013, 17:12
The manual says that LOCK will ensure that operation will be performed in atomic manner.
Meaning that no other thread will interrupt the instruction. I probably not needed the LOCK, because the value I use it on is DWORD aligned, so it is not likely that any other thread will interrupt it. Or maybe I am not understanding LOCK properly... I do not know. Anyhow, the manual will tell you the LOCK details better. I'll see if I can find that SPACEBAR bug. |
|||
15 Feb 2013, 17:12 |
|
JohnFound 15 Feb 2013, 18:33
AFAIK, LOCK is needed only when there are more than 1 CPU running.
|
|||
15 Feb 2013, 18:33 |
|
baldr 15 Feb 2013, 19:03
AsmGuru62,
LOCK prefix is more about multicore/SMP (not sure about HT), it ensures exclusive access to shared memory during load-modify-store instruction's execution. Since multicore CPUs are common today, it's safe bet. |
|||
15 Feb 2013, 19:03 |
|
AsmGuru62 16 Feb 2013, 00:41
I see.
Question: a single core is running, but DWORD is not aligned - is LOCK needed if other thread may interrupt the operation? |
|||
16 Feb 2013, 00:41 |
|
baldr 16 Feb 2013, 06:37
AsmGuru62,
Interrupt handling (within single core) is a synchronous event, despite it's caused by apparently asynchronous INTR/NMI/LINT signals. OTOH, simultaneous access by other core/bus master/memory-mapped device is inherently asynchronous (former two are serialized using cache coherency/bus locking protocols, latter one need additional synchronization efforts in case of multi-port memory). |
|||
16 Feb 2013, 06:37 |
|
typedef 16 Feb 2013, 10:58
Just hold SPACE and see what happens
|
|||
16 Feb 2013, 10:58 |
|
uart777 21 Feb 2013, 11:33
Nice little game, Guru! Way to go man!
However, I see no reason to create a separate thread: .loop [i]=0 to [n.programs] .if programs[i].active, update(programs[i]). Yes, it's that easy Last edited by uart777 on 21 Feb 2013, 18:55; edited 1 time in total |
|||
21 Feb 2013, 11:33 |
|
edfed 21 Feb 2013, 15:33
uart777 wrote: Nice little game, Guru! Way to go man! ... |
|||
21 Feb 2013, 15:33 |
|
AsmGuru62 21 Feb 2013, 17:50
Thanks, uart!
I still need to look at that SPACE bug. No time currently. Just want to mention that loops are not same as threads. They seem like the same thing, but 100% CPU says otherwise. |
|||
21 Feb 2013, 17:50 |
|
f0dder 21 Feb 2013, 19:54
AsmGuru62 wrote: The manual says that LOCK will ensure that operation will be performed in atomic manner. If you're doing multithreaded programming and you share read/write state across threads, unless you're explicitly targeting a single-core architecture, you need to synchronize access to the shared resource. For "small" pieces of data you can get away with atomic memory access - but as baldr says, even though you're only doing a single instruction (which will execute as an atomic unit, even if it's a load-modify-store like ADD), you'll need the LOCK prefix to ensure cache coherency between multiple CPU cores (whether they're on the same die or separate physical sockets). Also keep in mind that XCHG (possibly more, can't remember off top of my head) has an implicit LOCK when there's a memory operand, meaning it's grossly slow on multicore systems even when you don't need to share data between threads. For updates to larger data structures where you can't do atomic updates (and can't convert to lock-free data structures), there's multiple strategies. In general, it's usually best to use a mutex/semaphore/critical-section (depending on what your target OS offers), since those will usually remove your thread from the ready-list until it can gain access to the resource, which means it won't burn CPU cycles in the meantime. When you know a lock will only be held for a very short time, it can be better to "spin wait" with a spinlock; WIN32's CRITICAL_SECTION start off doing a few rounds of spinlooping before it turns to a off-the-ready-list mutex, it's a good general compromise. Also, check out "conditional variables" / "conditional mutex". uart777 wrote: know that small-minded bitch ass "fodder" wants to say some shit about me but he's NOTHING but a mindless follower, a Microsoft ass kisser. A toy pussy wannabe programmer who uses HL compilers all God damn day but comes online and poses a LL coder. What a bitch! fodder is nothing but a pussy ass dick sucking bitch who LOVES Windows 8. Now now, uart - be a good boy and take your medication. _________________ - carpe noctem |
|||
21 Feb 2013, 19:54 |
|
AsmGuru62 22 Feb 2013, 18:24
I see, thanks.
So, LOCK is needed when threads do Read/Write against a global variable, even if it is aligned. That is good to know. Yes, about the structures, I used the Critical Section in that game too. I am planning to write an emulator of a lottery machine. Gonna have some fun with threads! |
|||
22 Feb 2013, 18:24 |
|
baldr 22 Feb 2013, 22:17
AsmGuru62,
LOCK prefix is a needful evil, use it sparingly. One step further, and whoa! we do have dining philosophers' problem. Most interactive programs need only two threads: one to get responsive UI, another to do real things. Their interaction is, let's say, loose. |
|||
22 Feb 2013, 22:17 |
|
f0dder 22 Feb 2013, 23:18
baldr wrote: LOCK prefix is a needful evil, use it sparingly. It's one of the lesser evils - but yes, you should strive to avoid needing thread synchronization, since it can easily kill most of the performance you're able to get from parallelizing your code. It can be more efficient to allocate more memory and even do some "wasted" computations between threads in order to avoid synchronization. And immutable data is your friend _________________ - carpe noctem |
|||
22 Feb 2013, 23:18 |
|
KevinN 23 Feb 2013, 03:21
Thanks. I was thinking about cloning this: http://yppedia.puzzlepirates.com/Swordfight
not sure ive got the familiarity enough with fasm... its pretty cool, based off puzzle wars or whatever and multiplayer pvp |
|||
23 Feb 2013, 03:21 |
|
nmake 27 Feb 2013, 16:00
I didn't see this game until now, nice game and clean code.
|
|||
27 Feb 2013, 16:00 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.