Messages per Month
| From | Sent On | Attachments |
|---|---|---|
| Petri Helenius | Jan 6, 2005 7:36 am | |
| Petri Helenius | Jan 6, 2005 8:35 am | |
| David Xu | Jan 6, 2005 8:49 am | |
| Petri Helenius | Jan 6, 2005 9:15 am | |
| David Xu | Jan 6, 2005 9:22 am | |
| Niall Douglas | Jan 7, 2005 10:46 am | |
| David Xu | Jan 8, 2005 6:26 am | |
| Petri Helenius | Jan 8, 2005 10:24 am | |
| David Xu | Jan 10, 2005 4:07 pm | |
| Igor Sysoev | Jan 16, 2005 1:38 pm | |
| David Xu | Jan 18, 2005 6:12 am | |
| Julian Elischer | Jan 18, 2005 9:45 am | |
| David Xu | Jan 18, 2005 3:41 pm | |
| Ivan Voras | Jan 18, 2005 3:46 pm | |
| Julian Elischer | Jan 18, 2005 4:18 pm | |
| David Xu | Jan 19, 2005 3:20 am |
| Subject: | higher speed mutexes | |
|---|---|---|
| From: | Niall Douglas (s_so...@nedprod.com) | |
| Date: | Jan 7, 2005 10:46:27 am | |
| List: | org.freebsd.freebsd-threads | |
On 6 Jan 2005 at 18:35, Petri Helenius wrote:
because we use simple mutex to protect rwlock, if simple mutex is improved, rwlock should be improved by this side effect.
But rwlock will be significantly more expensive than a simple mutex when uncontested, right?
I have a highly optimised rwlock mutex implementation at http://svn.berlios.de/viewcvs/tnfox/trunk/src/FXThread.cxx?rev=52&view =markup. If uncontested, it requires no more than a variable increment and a TLS variable increment (with corresponding complexity for unlocking) for read locking and four variable increments, three variable stores, one TLS variable read for write locking. It's also fully recursive.
Cheers, Niall





