Upgrading read lock to a write one OR any other solution
Tigra
I have to deal with a big file split into pages with random access. I
constructed a skiplist of such pages with a key equal to a sequential
number of a page in the file. The algorythm of working with inRAM
cache is simple: check whether the page is present in the RAM, in case
it isn't get it from file (something like this is present for writing
data back). The memory for pages is preallocated with big chunks. Thus
I (hope ;) have a quick memory allocation. The issue is that several
threads have concurrent access to the page cache. Thus I (think) have
to use read locks on the elements of the list (the pages). And given
no page for the requested key I allocate a space for it and try to
read it (i.e. need to obtain a write lock).
I suppose mutexes will be of no help here.
So, is it possible to upgrade read locks to write locks using
pthreads?
Is there any alternative technique for this certain case?
Thanks,
Sergey
Arnold Hendriks
> to use read locks on the elements of the list (the pages). And given
> no page for the requested key I allocate a space for it and try to
> read it (i.e. need to obtain a write lock).
> I suppose mutexes will be of no help here.
Are you sure? A single mutex may be so much simpler than more complex
read/write (or other) locks, that just using a simple mutex may be a lot
faster than the extra time spent in more complex synchronization.
> So, is it possible to upgrade read locks to write locks using
> pthreads?
No, standard pthreads do not provide this. It's a bit more complex than
it may seem at first sight to create a generic upgradeable read/write lock,
what should happen when two read lock holders both wish to upgrade to a
write lock?
> Is there any alternative technique for this certain case?
Perhaps simpler locks become an option if you increase the granularity
of your locking? If it is possible to lock small sections (and you don't
risk deadlocks by lock extensions), a simple mutex may be good enough.
Another alternative may be to mmap the file instead of reading it into
memory. Various mmap options may allow you to write-protect parts of
the file, and it may make your job of managing the file a whole lot
easier.
--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/
Tigra
> Are you sure? A single mutex may be so much simpler than more complex
> read/write (or other) locks, that just using a simple mutex may be a lot
> faster than the extra time spent in more complex synchronization.
Seems you're right.
> > So, is it possible to upgrade read locks to write locks using
> > pthreads?
> No, standard pthreads do not provide this. It's a bit more complex than
> it may seem at first sight to create a generic upgradeable read/write lock,
> what should happen when two read lock holders both wish to upgrade to a
> write lock?
I thought it could be achieved somehow like this: Choose the lucky
one. Atomically decrease the read refcount and issue a write lock
(blocking).
> > Is there any alternative technique for this certain case?
> Perhaps simpler locks become an option if you increase the granularity
> of your locking? If it is possible to lock small sections (and you don't
> risk deadlocks by lock extensions), a simple mutex may be good enough.
>
> Another alternative may be to mmap the file instead of reading it into
> memory. Various mmap options may allow you to write-protect parts of
> the file, and it may make your job of managing the file a whole lot
> easier.
Just to clarify things. I'm using Linux 2.4 with LinuxThreads (the
version shipped with RH7.1). But I don't want to be stuck tightly to
only Linux. The task in general is to implement a rather simple
multi-user db engine. So I expect to handle files orders of magnitude
bigger than the amount of RAM.
The mmap(2) manpage says that accessing mmaped areas can cause SIGSEGV
and SIGBUS. How can I handle this? AFAIK one can't send a SysV signal
to a certain thread, so everyone will get it. Please point me if I'm
missing something.
Thanks,
Sergey
David Schwartz
> I thought it could be achieved somehow like this: Choose the lucky
> one. Atomically decrease the read refcount and issue a write lock
> (blocking).
There is no lucky one. Neither one can get a writelock until the other
releases their readlock. How would you use a upgradeable lock that might
cause you to lose your readlock?
DS
Alexander Terekhov
Just re-read/re-eval the stuff on NON-ATOMIC upgrade/switch...
regards,
alexander.
Joe Seigh
Tigra wrote:
...
>
> > No, standard pthreads do not provide this. It's a bit more complex than
>
> > it may seem at first sight to create a generic upgradeable read/write lock,
>
> > what should happen when two read lock holders both wish to upgrade to a
>
> > write lock?
>
> I thought it could be achieved somehow like this: Choose the lucky
> one. Atomically decrease the read refcount and issue a write lock
> (blocking).
...
There are other ways of implementing such a function using an extra mutex
so you don't have to deal with the unlucky thread issue.
/* get read lock w/ reserved upgrade to write lock */
pthread_mutex_lock(&mutex);
pthread_rwlock_rdlock(&rwlock);
...
/* upgrade to write lock */
pthread_rwlock_unlock(&rwlock);
pthread_rwlock_wrlock(&rwlock);
...
/* release lock */
pthread_rwlock_unlock(&rwlock);
pthread_mutex_unlock(&mutex);
/* get write lock */
pthread_mutex_lock(&mutex);
pthread_rwlock_wrlock(&rwlock);
...
/* release write lock */
pthread_rwlock_unlock(&rwlock);
pthread_mutex_unlock(&mutex);
/* get read lock */
pthread_rwlock_rdlock(&rwlock);
...
/* release read lock */
pthread_rwlock_unlock(&rwlock);
Joe Seigh
Alexander Terekhov
Tigra wrote:
>
> Thanks all of you (esp. John). Now I understand why guys discourage
> from using rwlocks.
I think that some guys just don't understand
that certain optimizations ARE possible with:
A) rw-locking without upgrade option, in general;
B) rw-locking WITH upgrade option AND atomic/NON-
atomic/upgrade-pending indications, in particular.
regards,
alexander.
Tigra
> Thanks all of you (esp. John). Now I understand why guys discourage
> from using rwlocks.
Joe, I beg your pardon for misspelling the name. Really.
Sorry,
Sergey