flat assembler
Message board for the users of flat assembler.

Index > Tutorials and Examples > A small Win32 game (2 threads) example

Author
Thread Post new topic Reply to topic
AsmGuru62



Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada
AsmGuru62 29 Jan 2013, 18:16
I wrote this testing my FASM Writer during Christmas time in 2011.
Read the ReadMe.Txt.
Smile


Description: Source Code Only (No EXE)
Download
Filename: MapNetCols.zip
Filesize: 16.4 KB
Downloaded: 1010 Time(s)

Post 29 Jan 2013, 18:16
View user's profile Send private message Send e-mail Reply with quote
Picnic



Joined: 05 May 2007
Posts: 1403
Location: Piraeus, Greece
Picnic 15 Feb 2013, 16:53
Very nice AsmGuru62, the game runs fine on my XP. I like your style. Can you please give me more info about using lock prefix on threads. lock add [...

p.s I faced a minor bug, if i press and hold spacebar for 5-10 seconds game crashes sometimes.
Post 15 Feb 2013, 16:53
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada
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.
Post 15 Feb 2013, 17:12
View user's profile Send private message Send e-mail Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 15 Feb 2013, 18:33
AFAIK, LOCK is needed only when there are more than 1 CPU running.
Post 15 Feb 2013, 18:33
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
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.
Post 15 Feb 2013, 19:03
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada
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?
Post 16 Feb 2013, 00:41
View user's profile Send private message Send e-mail Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
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).
Post 16 Feb 2013, 06:37
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 16 Feb 2013, 10:58
Just hold SPACE and see what happens

Evil or Very Mad
Post 16 Feb 2013, 10:58
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777 21 Feb 2013, 11:33
Nice little game, Guru! Way to go man! Wink

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 Smile


Last edited by uart777 on 21 Feb 2013, 18:55; edited 1 time in total
Post 21 Feb 2013, 11:33
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 21 Feb 2013, 15:33
uart777 wrote:
Nice little game, Guru! Way to go man! Wink

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 Smile

I 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.

fodder: Never fuck with me, I'll murder you programatically.

...
Post 21 Feb 2013, 15:33
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada
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.
Post 21 Feb 2013, 17:50
View user's profile Send private message Send e-mail Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 21 Feb 2013, 19:54
AsmGuru62 wrote:
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.

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.

fodder: Never fuck with me, I'll murder you programatically.

Now now, uart - be a good boy and take your medication.

_________________
Image - carpe noctem
Post 21 Feb 2013, 19:54
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada
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.
Smile

I am planning to write an emulator of a lottery machine.
Gonna have some fun with threads!
Post 22 Feb 2013, 18:24
View user's profile Send private message Send e-mail Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
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. Wink

Most interactive programs need only two threads: one to get responsive UI, another to do real things. Their interaction is, let's say, loose.
Post 22 Feb 2013, 22:17
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
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 Smile

_________________
Image - carpe noctem
Post 22 Feb 2013, 23:18
View user's profile Send private message Visit poster's website Reply with quote
KevinN



Joined: 09 Oct 2012
Posts: 160
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
Post 23 Feb 2013, 03:21
View user's profile Send private message Reply with quote
nmake



Joined: 13 Sep 2012
Posts: 192
nmake 27 Feb 2013, 16:00
I didn't see this game until now, nice game and clean code. Smile
Post 27 Feb 2013, 16:00
View user's profile Send private message 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-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.