Re: Semantics of copying mutex/rwlock

[Sad Clouds <cryintothebluesky%googlemail.com@localhost>]

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.