| Re: [AD] Thread api and rwlocks |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
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.
--
Elias Pschernig <elias.pschernig@xxxxxxxxxx>