STM in games

I wander does anybody uses something like STM in games?

I did try something like it in the last LD – my game used what I would call a lightweight STM. Meaning that had two threads of execution – a reader thread (which is actually performing the painting, based on a given game state) and a writer thread (which actually moves the game state ahead, the update loop).

The writer threads starts a “transaction” and it is working with its private copy of the value. When commits, the value becomes visible to the reader/painter thread.

The main advantage of the approach is that we can use easy multi-threading (even utilize multiple cores) with clear separation between who makes updates and who makes the drawing on screen. The only negative I see is that we cannot use directly the values provided by the language but instead should wrap every peace of data in another layer/abstraction.

Any thoughts?

Comments

SusanTheCat
30. Aug 2011 · 13:00 UTC
Since I don’t mind looking stupid, what do you mean by STM? I would assume some sort of thread management, but what does the S stand for?
SusanTheCat
30. Aug 2011 · 14:05 UTC
Thanks for the link!
Felipe Budinich
30. Aug 2011 · 14:31 UTC
Will read the link. The closer we have to multithreading (us lowly flash developers) is pixel bender :-p