Groups > Novell > Novell Libc > Re: file locking




file locking

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
<< Previous 1 2 3 Next >>
( Page 1 of 3 )
about | contact