tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Semantics of copying mutex/rwlock



On Jun 17, 12:18am, cryintothebluesky%googlemail.com@localhost (Sad Clouds) 
wrote:
-- Subject: Re: Semantics of copying mutex/rwlock

| On Wed, 16 Jun 2010 21:42:03 +0000 (UTC)
| christos%astron.com@localhost (Christos Zoulas) wrote:
| 
| > Why do it in the first place? What are you doing with the old mutex?
| 
| Yeah this sort of thing doesn't come up very often. I've been
| developing a concurrent hash table that can be used effectively by
| hundreds of threads. This is going to be used for a larger project I'm
| working.
| 
| I'm actually using pthreads read/write locks, since hash tables are
| mainly used for read-only data look up. I want to be able to
| dynamically resize the hash table as more data is added to it. Resizing
| the hash table is what made me think about copying pthreads locks.
| 
| The way hash table is implemented is this:
| 
| There is one global hash table read/write lock. If a thread wants to
| resize the hash table, it must obtain write-lock on it.
| 
| Hash table buckets are protected by a set of read/write locks. The
| number of bucket locks is much smaller than the total number of
| buckets. It depends on how many concurrent threads you have and what
| level of concurrency you want to achieve. You can specify all these
| parameters during hash table init() function.
| 
| Bucket locks are striped over the buckets, e.g:
| 
| bucket_index = key_hash_code % nbuckets;
| lock_index = bucket_index % nlocks;
| 
| pthread_rwlock_rdlock(&locks_array[lock_index]);
| 
| If I expand the number of hash table buckets, I need to expand the
| number of locks, otherwise concurrency might suffer. Locks need to be
| indexed sequencially as array elements, so you have to allocate a
| larger array. Originally I would destroy locks in old array and
| recreate them in new array, but now I'm redoing this with array of
| pointers to locks, which are dynamically allocated in groups and stored
| in linked list.

That sounds like the right and portable way of doing it (pointers to locks)...

christos



Home | Main Index | Thread Index | Old Index