Re: [Dev-C++] Multi threading in game

[Philip B. <phi...@pb...>]

Hi Per,

Thanks for all the help. You gave some great information, as always.

The game is realtime, meaning that more than one thread will have to modify 
the enemy at the same time (the data cannot be cashed). The player thread 
will look for the enemies when the player walks for instance which means 
reading, or when he fires to see if an enemy was hit which means writing if 
the enemy needs to be woonded. So you think it's safe to have a critical 
section for each enemy? That's the way I originally planned it but I thought 
that maybe entering and leaving all these critical sections constantly would 
take up too much processor power.

It's a good idea having several critical sections for each character 
depending on the action performed, but in this case it's not really an 
option because all it really does is to read and modify members in a struct.

Regards
Philip Bennefall
----- Original Message ----- 
From: "Per Westermark" <pw...@ia...>
To: "Philip Bennefall" <phi...@pb...>
Cc: <dev...@li...>
Sent: Tuesday, November 13, 2007 3:07 AM
Subject: Re: [Dev-C++] Multi threading in game


> My guess is that the code you perform in an enemy is very quick (probably
> microseconds) so waiting for a lock shouldn't be a problem.
>
> Having one big critical section is more important if you have a _huge_
> amount of objects and have to think about consumed resources. If you can,
> it is better to have a granular solution, where you lock small sections.
> 1) It gives less chance of a collision.
> 2) It will probably be locked for a shorter time - you don't get tempted
> to take a lock and then iterate through all objects and perform
> mass-updates.
>
> There might even be situations where it might be meaningful to have more
> than one lock/object. Some actions may for example only affect (or be
> accted by) a limited set of object properties, while other actions may
> affect (or be affected by) a different set of properties.
>
> A separate issue: Do all objects make their decisions based on the
> "current" state, or do you make a snapshot of all state and base the next
> action on the snapshot state? If everything is real-time, then it is
> reasonable to walk through all objects continuously in a round-robin. If
> the game is turn-based (or pseudo-realtime) then all objects decides what
> will happen based on a locked state and then all objects switches to the
> new state before making new decisions. In this case, you need hardly any
> locking at all. Only one thread is responsible for updating each object,
> and the input state is fixed until all book-keeping has been done. Then
> all threads can decide to lock their huge locks, switch to next state and
> then release the locks and start deciding on next state.
>
> About total CPU load: Need all enemies be awake? Many games can sleep all
> enemies more than a specific distance from a player. What you can't see,
> you can't complain about, if you excuse the pun :)
>
> /pwm
>
> On Tue, 13 Nov 2007, Philip Bennefall wrote:
>
>> Hello everyone,
>>
>> This will be a rather long message.
>>
>> I have a question regarding multi threading and syncrhonization for a
>> game that I'm working on. The game will have hundreds of objects
>> (enemies, bullets and so on), and I am trying to think of an efficient
>> way to implement this using multiple threads.
>>
>> I will have input and player actions in one thread since they are tied
>> together, window message processing in the main thread which will be
>> idle for the most part, and then a thread which handles the enemies. I
>> will give them different priority levels so that they don't all move at
>> full speed all the time. I have two ideas for how to do this:
>>
>> 1. Give each enemy its own critical section object so that it is free
>> whenever it is not being read or written to. Then whenever the player
>> thread or another enemy in the same thread wants to access it either for
>> reading or writing, it'll enter the critical section. I figure that this
>> could potencially cause delays, for example what if an enemy decides to
>> move while the player is firing at it and thus modifying its data from a
>> different thread?
>>
>> 2. Have a critical section for all the enemies, which I guess would
>> not be very practical but it is one idea that I had.
>>
>> Can anyone perhaps suggest a good way of handling this? I want to be
>> able to read and write the enemy information from any thread as fast as
>> possible, though most of the work will occur in one and the same thread
>> (the enemy thread).
>>
>> Thanks in advance for any help.
>>
>> Regards
>> Philip Bennefall
>
>