News
Workshop interne avec l’équipe de l’EPFL-ECAL-lab pour évaluer lubyk. Si tout va bien, on aura quelques démos à mettre en ligne…
Nous travaillons actuellement sur le spectacle des bateaux pour nulle part prévu pour l’automne 2012.
RW mutex testing
Testing threads is fun: seeing how each one gets execution time in turn and which ones are greedy or starving makes them look like animals competing for food.
For oscit, I am writing a read/write mutex (many concurrent readers, one writer at a time).
The tests below correspond to an implementation using a hand made read/write mutex using a semaphore and an acquire mutex.
Here are some plots of execution interleaving. A . represents a reader’s read operation. + is writer1’s signature and = is writer2.
Each thread (2 writers + readers) loops 1000 times. The maximum number of readers at once is 16.
20 readers, max 16 readers at once
See how the readers do all their job before the writers and how these finish their tasks when all the readers have died (bottom line) ?
2000 readers, max 16 readers at once
With many more readers then writers and the same resource count (16), the work is more evenly distributed.
2000 readers, max 2000 readers at once
The same distribution pattern as with 20 readers appears here. This means that if the readers to max_readers ratio is too big, the writers tend to starve.
using rwlock
Tests using a posix rwlock shows better or worse results (speed) depending on the number of readers and writers. Using a typical situation (20 readers / 2 writers) shows much faster results using rwlocks.