Problem with apr_proc_mutex

[Rohan Nandode <rn...@yahoo.com>]

Hi,

  Apologies for posting it here, but haven't got any
response in dev@apr.httpd.org.

  I am using APR library on Linux system where it uses
SystemV type locking mechanism. I am seeing a problem
with inter process locking- apr_proc_mutex_XXX
functions.
  I want to create a inter process lock to serialize
to process. What I have done is:
1. Created a apr_proc_mutex_t with a valid lock file
name in a process and aquired a write lock on it. Both
the operations were successful.
2. In second process, I created a apr_proc_mutex_t
mutex with same filename as in above and acquired a
lock. Again both are successful.
3. Both the mutexes are created with DEFAULT mechanism
and which is SystemV type.

What I am wondering is, eventhough in #1 a process has
acquired a lock, second process (in #2) can again
acquire a lock for same file name. Effectively
violating the locking.

After debugging, what I found is:
Both the processes create a separate semaphore and
hence both can acquire lock on same file.

What would be the cause of this? or Am I using valid
APR APIs to create inter process locking?
If not, then please let me know how to do it.

Thanks a lot
Rohan

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: Problem with apr_proc_mutex

[Rohan Nandode <rn...@yahoo.com>]

Hi,

  Thanks for all the responses!

> 2. you probably want to be explicit, anyways, about
> your mutex method,
>    e.g. try this list in order...
> 
>     APR_LOCK_FCNTL

I tried to use APR_LOCK_FCNTL locking method. But it
is also giving same problems. What I observed in FCNTL
locking is,
1. First process while creating a mutex opens a lock
file, gets the fd and stores it for further
operations. Then it unlinks the file.
2. When second process creates mutex, it again creates
a file, stores the fd and deletes it.
3. Even though lock file name is same in the
processes, the fd's are independant.
   Hence both processes can get the write lock
simultaneously.

4. If both processes create mutexes
simultaneously(before unlinking the lock file by
either of them), then it works fine.

What would be the solution for this apart from using
APR_LOCK_FLOCK? 

Thanks
Rohan

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com

Re: Problem with apr_proc_mutex

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 02:03 AM 3/27/2003, Rohan Nandode wrote:
>Hi,
>
>  Apologies for posting it here, but haven't got any
>response in dev@apr.httpd.org.
>
>  I am using APR library on Linux system where it uses
>SystemV type locking mechanism. I am seeing a problem
>with inter process locking- apr_proc_mutex_XXX
>functions.
>  I want to create a inter process lock to serialize
>to process. What I have done is:
>1. Created a apr_proc_mutex_t with a valid lock file
>name in a process and aquired a write lock on it. Both
>the operations were successful.
>2. In second process, I created a apr_proc_mutex_t
>mutex with same filename as in above and acquired a
>lock. Again both are successful.
>3. Both the mutexes are created with DEFAULT mechanism
>and which is SystemV type.

Rohan, the implementation today is quite fork()-centric, meaning
the mutexes are generally used between sibing processes that inherit
the mutex.  Since you have two seperate processes, we need to look
at that;

1. our APR_LOCK_SYSVSEM isn't a name-based lock.

2. you probably want to be explicit, anyways, about your mutex method,
   e.g. try this list in order...

    APR_LOCK_FCNTL
    APR_LOCK_FLOCK

3. failing that, we have a bug in APR_LOCK_POSIX that the fname passed
   is ignored, so a random one is invented, but a patch at line 129 of
   proc_mutex.c could make that hassle disappear.

4. finally it seems like APR create_mutex should have a 'named lock' flag 
   that allows the user to insist on a named (cross-process) lock instead 
   of any anonymous lock.

The reason you had no response is you mailed the wrong list - please use
dev@apr.apache.org for this sort of discussion about the portability library!

Bill