Re: [AD] Thread api and rwlocks

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Sat, 2010-05-01 at 08:59 -0600, Thomas Fjellstrom wrote:
> > 
> > 
> > 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.
> 

I see - rwlocks indeed would make your case simpler to implement. With
what we have now you'd need to do your own checking at the start and end
of the access. Something like:

ALLEGRO_MUTEX *mutex;
ALLEGRO_COND *cond;
int readers = 0;

reader() {
    al_lock_mutex(mutex);
    readers++;
    al_unlock_mutex(mutex);

    ...

    al_lock_mutex(mutex);
    readers--;
    if (readers == 0) al_signal_cond(cond);
    al_unlock_mutex(mutex);
}

writer() {
    al_lock_mutex(mutex);
    while (readers > 0) al_wait_cond(cond);

    ...

    al_unlock_mutex(mutex);
}

If we had the pthreads rwlock the same thing could look like:

ALLEGRO_RWLOCK rwlock;

reader() {
    al_lock_rwlock_read(rwlock);

    ...

    al_unlock_rwlock(rwlock);
}

writer() {
    al_lock_rwlock_write(rwlock);

    ...

    al_unlock_rwlock(rwlock);
}

So well, I'm not against adding it, your use case seems quite common and
the condition variable solution is probably out of reach for anyone who
didn't read up on threads.

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>