Question about persistence of pthread_rwlock_t
Ken Savela
several processes (Solaris 2.8, if it matters). The trie (and the data
it contains) will be stored in a file that is mmap'ed into each process
at a well known address. Each process may access this shared structure
on one or more threads. To synchronize access to the trie, I want to
use a pthread_rwlock_t that lives in the memory-mapped file. This would
be initialized (along with other things in the memory mapped file) by a
"builder" utility.
Here's my question: Am I correct in assuming that this will work; that
is, can I initialize this synchronization object in shared memory (by
way of a memory mapped file), unmap the file, and exit the builder
process and expect other processes that will be started later in the day
to be able to successfully synchronize on this object?
Joe Seigh
Good question. There's nothing to say that it wouldn't work. Of course
there is nothing to say that it would work.
It is an opaque data type so you'd have to be careful. You couldn't assume
that is self contained. If it was you'd probably be ok. However, if it
was a handle to a system resource, then the os would likely have a mechanism
to free up resources when it determines they are no longer in use. You
couldn't rule that out on all platforms at least.
Of course unix has ipc semaphores which don't free up unless you explicitly
free them, so os'es don't have to automatically free resources.
Joe Seigh
Roger A. Faulkner
This will work on Solaris. I don't know about other platforms.
Of course, if one of your processes grabs the lock and then
terminates abnormally, it leaves the lock held even though
the owner is dead. You have to implement some sort of
cleanup program to recover from this.
Roger Faulkner
roger.f...@sun.com
Alexander Terekhov
[...]
> Of course, if one of your processes grabs the lock and then
> terminates abnormally, it leaves the lock held even though
> the owner is dead. You have to implement some sort of
> cleanup program to recover from this.
How? I mean: does POSIX actually define any semantics
that would allow to completely get rid of "abandoned"
locks (i.e. any "internal" resources perhaps maintained
by the implementation too)?
A reference, please!
regards,
alexander.
Dragan Cvetkovic
No, I don't think there is such a mechanism. Something like SEM_UNDO for
semaphores would be nice to have, but I don't think there is OS support for
this. Of course, I could be proven wrong, and I wish somebody does. It
would make my programmer's life easier.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
Roger A. Faulkner
Sorry, recovery from these situations is left up to you.
If your data is left in an inconsistent state because
one of your processes malfunctioned and died before
releasing the lock, only you have the knowledge
to clean it up.
Roger Faulkner
roger.f...@sun.com
Alexander Terekhov
Roger, the data is my problem indeed (and I could
easily solve it). My question was about *LOCKS*.
regards,
alexander.
Roger A. Faulkner
Alexander Terekhov <tere...@web.de> wrote:
>
>"Roger A. Faulkner" wrote:
>>
>> In article <3C92063F...@web.de>,
>> Alexander Terekhov <tere...@web.de> wrote:
>> >"Roger A. Faulkner" wrote:
>> >[...]
>> If your data is left in an inconsistent state because
>> one of your processes malfunctioned and died before
>> releasing the lock, only you have the knowledge
>> to clean it up.
>
>Roger, the data is my problem indeed (and I could
>easily solve it). My question was about *LOCKS*.
Just reinitialize them after you have fixed up the data.
There is no magic to it.
Roger Faulkner
roger.f...@sun.com
Alexander Terekhov
"Roger A. Faulkner" wrote:
>
> In article <3C936EB1...@web.de>,
> Alexander Terekhov <tere...@web.de> wrote:
> >
> >"Roger A. Faulkner" wrote:
> >>
> >> In article <3C92063F...@web.de>,
> >> Alexander Terekhov <tere...@web.de> wrote:
> >> >"Roger A. Faulkner" wrote:
> >> >[...]
> >> Sorry, recovery from these situations is left up to you.
> >> If your data is left in an inconsistent state because
> >> one of your processes malfunctioned and died before
> >> releasing the lock, only you have the knowledge
> >> to clean it up.
> >
> >Roger, the data is my problem indeed (and I could
> >easily solve it). My question was about *LOCKS*.
>
> Just reinitialize them after you have fixed up the data.
> There is no magic to it.
Uhmm. You wrote:
http://groups.google.com/groups?as_umsgid=a6qs0g%245hq%241%40engnews2.Eng.Sun.COM
"Of course, if one of your processes grabs the lock and then
terminates abnormally, it leaves the lock held"
Now, let us click here:
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_rwlock_destroy.html
"Results are undefined if pthread_rwlock_init() is called
specifying an already initialized read-write lock"
"Results are undefined if pthread_rwlock_destroy() is called
when any thread holds rwlock"
"The pthread_rwlock_destroy() function may fail if:
[EBUSY] The implementation has detected an attempt to destroy
the object referenced by rwlock while it is locked."
So, either your statement "There is no magic to it" is NOT true,
(and there IS some magic to it) or (as Butenhof once said on
comp.std.c++) "your response was a total nonsequitur. ;-)" ;-)
(a wink from me too).
Or perhaps I am totally off mark here and the right answer
is awaiting me somewhere on www.opengroup.org web pages...
If so, "A reference, please!"... and I even apologize in
advance! ;-)
regards,
alexander.
K Savela
> In article <3C936EB1...@web.de>,
> Alexander Terekhov <tere...@web.de> wrote:
> >
> >"Roger A. Faulkner" wrote:
> >>
> >> In article <3C92063F...@web.de>,
> >> Alexander Terekhov <tere...@web.de> wrote:
> >> >"Roger A. Faulkner" wrote:
> >> >[...]
> >> Sorry, recovery from these situations is left up to you.
Hello. Thanks for your responses. I spent some time thinking about the
problem at hand and I've found that I can make operations on the trie
thread-safe if (and only if) I restrict the insertions (we don't delete
anything) to a single thread. Since the vast majority of operations
will be lookups this won't be hard to do. This eliminates the need for
my read-write lock.
There is still, however, a need to synchronize updates to the individual
items contained in the trie. For this, I plan to provide each
individual data record with a mutex (again, in shared, mmap'ed
memory). This does, indeed, work on Solaris 2.8 (thanks Roger) but
there is the nasty little issue of a process dying with a mutex locked.
The thread library (native Sun, not POSIX) we're using with Solaris 2.8
has a neat enhancement: you can call mutex_init with a type parameter of
USYNC_PROCESS_ROBUST. A mutex_t initialized this way will cause
mutex_lock to return an error of EOWNERDEAD if another thread has locked
the mutex and its process dies before it gets a chance to unlock the
mutex. Not only does this solve the problem of blocking forever on a
mutex but it also gives us a clear indicator that the data with which
the mutex is associated will have to be verified, and possibly fixed,
before being used.
Since we'll be running exclusively on Sun boxes, I don't have a big
problem using the Sun native thread library but, ceteris paribus, I'd
prefer to use POSIX threads. Does anybody know if such a feature is
planned for POSIX threads?
Thanks again.
Ken
Roger A. Faulkner
You wanted to know if/how it works on Solaris.
I answered that. It just works.
I can't speak for other systems.
The standards man pages say bad things *might* happen if you
destroy and/or reinitialize a lock after the owner dies.
On Solaris, they don't, so long as you don't reinitialize
a lock while some thread/process in the system is using it.
Of course, this discussion is unnecessary if none of your
processes ever malfunctions.
Roger Faulkner
roger.f...@sun.com
Alexander Terekhov
"Roger A. Faulkner" wrote:
[...]
Nope. On "POSIX"; SUSv2/3 if you like.
> I answered that. It just works.
> I can't speak for other systems.
Ok. Thanks. Is this a *documented*
feature of pthreads/Solaris?
regards,
alexander.
Alexander Terekhov
No, it is NOT, Roger. Your official docu
basically mirrors IEEE specs:
http://docs.sun.com:80/ab2/coll.40.6/REFMAN3D/@Ab2PageView/57431?Ab2Lang=C&Ab2Enc=iso-8859-1
Gurus, how about something (system call)
that would allow us to get rid of ALL
synch objects from this or that shared
memory object?
regards,
alexander.
Steve Watt
Alexander Terekhov <tere...@web.de> wrote:
>Gurus, how about something (system call)
>that would allow us to get rid of ALL
>synch objects from this or that shared
>memory object?
That's a silly task for the general case. If a mutex contains something
like a file descriptor/index into system table/whatever, there's no
way to detect whether the particular copy of the value 6 is the shared
memory object is a mutex or something completely different.
It's admittedly possible, but with some overhead. Each synchronization
object could be stuck on a list somewhere that somehow managed to
correlate with the virtual memory system such that when a particular
object was destructed (and what about mmap()ed files that might be long
unmapped before the disk space gets reclaimed?) Good Things happen.
Heck, I'm even aware of such a system, but the implementation has
almost certainly improved by now.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...