Re: [Algorithms] Message Passing

[Nicholas \Indy\ R. <ar...@gm...>]

Hrm, it seems that perhaps I misunderstood, are you talking about
using a queue of messages for the next thread, and to not read from it
until it's been swapped?

In that case, a mutex is only needed on the swapping, IF only one
thread is allowed to write to the queue.

But in this case it looses a lot of practicality, for a few reasons,
If only one thread is allowed to write, then objects can't receive
messages from more then one other object.

Additionally the whole idea of double buffered message queues are a
bit flawed, as it'll introduce a frame of lag before the receiving
object can respond. Take the case of a player shooting a bullet; A
standard approach would have at minimum an input object, player
object, and a gun object, each message would have a frame of lag:

input -> player -> gun -> projectile spawn

That gives a 3 frame lag on shooting a single bullet I'm sure you can
understand how that could become unpractical very quickly.

Correct me if I misunderstood.

Indy

On Mon, Mar 9, 2009 at 12:18 AM, Oscar Forth
<os...@tr...> wrote:
>> Additionally, you can't really implement such a queue on any of the
>> std containers as they are not thread-safe (And a contiguous memory
>> container such as a vector has even more problems.). So you would
>> really have to wrap every access in a mutex and that would kill
>> performance, a lock-free queue is a much better approach.
>
>
> But surely you only need to critical section when you swap the current frame
> and next frame buffers over?
>
> Though I guess you'd need to check the critical section the rest of the time
> just to see if the swap is in progress ... hmmm.
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>