|
| file locking |
 |
Thu, 08 Nov 2007 17:03:42 GMT |
Hi everyone,
is there anything out, that reliable locks between two separate NLMs
within the same protected address space (or even more global)?
fcntl() doesn't work as advertised
flock() same as fcntl
MXFileRangeLock looks like is not reiable eg
from:
http://developer.novell.com/documentation//libc/index.html?page=/documentation//
libc/libc_vol1/data/agbuo5h.html
MXFileRangeLock
The lock requested is advisory. This means that the system does not
ensure that only the lock owner is allowed to perform IO operations in a
locked region. Co-operating applications are expected to perform IO
operations only after successfully acquiring a byte range lock of the
required type.
I need to access the same dat file across multiply NLMs. Most of them
just read it, however one NLM has duties to update it frequently. So it
has to lock the file, update and release it again. Meanwhile the other
nlm's should just wait. I am happy with anything that solves this problem.
Greetings,
|
| Post Reply
|
| Re: file locking |
 |
Sat, 10 Nov 2007 16:30:08 GMT |
Hi Xatru,
Xatru <xatru@kuehlbox.de> wrote in
news:OjHYi.3088$7U6.1910@kovat.provo.novell.com:
> Hi everyone,
>
> is there anything out, that reliable locks between two separate NLMs
> within the same protected address space (or even more global)?
semaphores?
http://developer.novell.com/documentation/libc/libc_vol2/index.html?
page=/documentation/libc/libc_vol2/data/akqakys.html
Günter.
|
| Post Reply
|
| Re: file locking |
 |
Sat, 10 Nov 2007 19:11:12 GMT |
>> is there anything out, that reliable locks between two separate NLMs
>> within the same protected address space (or even more global)?
> semaphores?
> http://developer.novell.com/documentation/libc/libc_vol2/index.html?
> page=/documentation/libc/libc_vol2/data/akqakys.html
Hi Günther, thanks for your response.
I have looked at the page, but this looks like only thread
synchronization. For that, I use pthread mutexes. However they woun't
work over multiply separate NLM instants.
How should be the semaphore shared over the other nlms? Have I overseen
something? In the other hand, aren't they dangerous when it comes to
deadlocks. If one NLM (ab)ends, probably all others will be deadlocked
waiting for the lock to get released. For file-locks at least the OS
would release the lock when the program terminates or ends.
But for now, I even would accept a semaphore. You have a sample or hint
how to share such a lock over multiply nlm's ?
Thanks in advance,
|
| Post Reply
|
| Re: file locking |
 |
Mon, 12 Nov 2007 02:09:57 GMT |
Hi Xatru,
Xatru <xatru@kuehlbox.de> wrote in news:knnZi.4098$7U6.3110
@kovat.provo.novell.com:
> But for now, I even would accept a semaphore. You have a sample or hint
> how to share such a lock over multiply nlm's ?
no, it was just a suggestion defived from former discussions here about that
the flock API seems somehow broken....
I've asked the LibC developer to jump in here - lets hope he finds some time
to clarify.
greets, Günter.
|
| Post Reply
|
| Re: file locking |
 |
Mon, 12 Nov 2007 15:39:45 GMT |
The big assumption is that when the thread abends, that the cleanup
routine for the address space can unlock and close the file. If it is
able to do this, it may also be releasing any semaphores the threads
held. :-) If that is true, then you can use semaphore and file lock
interchangeably if your NLM's are the only things accessing the files.
I don't know if semaphores are cleaned up in this way or not. I hope
they are. But I can see arguments why you'd NOT want to. Its easy to
find out though.
And the named semaphore is a inter-NLM solution. You can create
"BobsFamousSemaphore" in one NLM and access that semaphore from
another.
And it IS a thread control mechanism, which is a decidedly GOOD thing.
If anything the semaphores are more efficient that a while( ! locked )
sleep() construct. As the OS knows when the semaphore is released and
will wake the threads in the kernel essentially in-line. So it should
be a way more efficient solution than spinning.
As for deadlocks... yeah, sure if one of the app threads abends, then
survivability is an issue. If the abends happens during a write, do
you really know anything? The file could be partially updated, and
that would lead to a mess later. If the abend is during a read, then I
get your point...
If the abend cleanup does reliably clean the in-use count for the
semaphores, then that's a viable solution.
-- Bob
- - - - - - - - - - - - - - - - -
Robert Charles Mahar
Traffic Shaping Engine for NetWare
http://www.TrafficShaper.com
- - - - - - - - - - - - - - - - -
Xatru wrote:
>>> is there anything out, that reliable locks between two separate
NLMs
>>> within the same protected address space (or even more global)?
>> semaphores?
>> http://developer.novell.com/documentation/libc/libc_vol2/index.html?
>> page=/documentation/libc/libc_vol2/data/akqakys.html
>
> Hi Günther, thanks for your response.
>
> I have looked at the page, but this looks like only thread
> synchronization. For that, I use pthread mutexes. However they woun't
> work over multiply separate NLM instants.
> How should be the semaphore shared over the other nlms? Have I overseen
> something? In the other hand, aren't they dangerous when it comes to
> deadlocks. If one NLM (ab)ends, probably all others will be deadlocked
> waiting for the lock to get released. For file-locks at least the OS
> would release the lock when the program terminates or ends.
> But for now, I even would accept a semaphore. You have a sample or hint
> how to share such a lock over multiply nlm's ?
>
> Thanks in advance,
>
|
| Post Reply
|
|
|
|
|
|
|
|
|
|