Re: [AD] Thread api and rwlocks

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On May 1, 2010, Elias Pschernig wrote:
> On Sat, 2010-05-01 at 03:31 -0600, Thomas Fjellstrom wrote:
> > Do you think it makes sense for allegro to provide a wrapper for
> > rwlocks as well? I can see myself using them if it did.
> 
> Hard to say for me. I tend to believe the mutexes we use in Allegro are
> mostly uncontended - so whether we optimize them with rwlocks (or even
> atomic operations, for example SDL has those) or not should not result
> in any measurable performance increase. However I might be wrong... so
> not sure, ideally we'd first know how much performance increase we can
> expect before making the API more complex.
> 
> > I guess it depends if windows
> > supports the same kind of locks.
> 
> Could always fall back to a normal lock on platforms which only support
> those.
> 
> 
> I guess once it's common for games to use 16 or 32 cores things like
> this will be more important... but then again I can't see a problem with
> distributing your AI's Lua scripts to threads and synchronize access to
> the game state with good old al_lock_mutex.
> 
> Only fine-grained parallelism likely needs something else. And if your
> physics library uses massive parallel algorithms it has to use its own
> primitives anyway and not Allegro's. The advantage for us would be that
> things stay really simple - everyone can grasp al_[un]lock_mutex in 5
> minutes and have their game load the next level in the background.
> Anything else likely will be very confusing for newcomers.

I completely disagree. RW locks are for specific access patterns. It doesn't 
matter if you only have 2-4 cpus, they are a big help with some patterns. 
Like lots of reads, and few writes.

For my Canva5 project, if I wanted to give each Display its own thread, I 
can see them contending in the Model class a lot. But Display::paint only 
READs so theres no reason either threads need to do a full lock when 
painting. Only when updating will a write lock be taken.

I just don't want to have to depend separately on pthreads, or do my own 
cross platform threading.

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx