Sponsored Content
Full Discussion: Atomicity
Top Forums Programming Atomicity Post 50800 by S.P.Prasad on Monday 3rd of May 2004 02:02:58 AM
Old 05-03-2004
Atomicity

I am working on a primitive project ported on AIX Unix Box. Earlier this system used to run on VMS VAX and DEC Alpha system. The major source code files are written in FROTRAN.

Across process data are exchanged through FROTRAN COMMONS and a specific locking mechanism is implemented for resource synchronization. Data for exchange are stored in FROTRAN Array in COMMONS. During addition to the bottom of the array and removal from the top, a specific position of the array is marked as 1 or 0 meaning that array can be accessed or cannot. Based upon these values the action on arrays would be taken. I hope that I am clear.

They used LIB$BBSSI() system call to lock the list and LIB$BBCCI() system call to release the list from lock state in VMS. I presume that this would be atomic cause of which process where in synchronization.

During porting of the same software in Tru64 they swapped the same routines with C subroutines _TESTBITSSI() and _TESTBITCCI() calls.

The problem came when they ported it to AIX. Due to lack of technology specifications we are unable to have atomic locking mechanism. Hence the issue is that two or more process is able to detect that they can act on a same array resulting on an unpredictable behavior.

We need a solution for the problem. I though of a solution but I don't know that in multi-process environment whether the solution would work or not. Please provide your necessary input and ensure that the code does leads to a DEADLOCK.
:

During the process startup we would store the required address our interest. Say for example we have 3-array list and list lock index is 1. So if the arrays are named as A, B, D then we will store the address of A (1), B (1) and D (1) in ‘C' array of pointers *list_arr[3] (list_arr[0], list_arr[1], list_arr[2]).
Now LOCK() and REL() subroutine would be called across process running in different address space.

LOCK(int *bit_pos, int *address)
{
.......
.......
/* For One specific address */
RERUN:
if ( address == list_arr[0] )
{
if ( shared_variable_One == 0 ) /* Variable Shared Across Processes */
{
shared_variable_One = getpid ( ) ;
}
if (shared_variable_One == getpid ( ) )
{
if ( ++ shared_variable_two > 1 ) /* Variable Shared Across Processes Initially initialized as 0*/
goto RERUN:
/* Set the bit value */
shared_variable_One = 0 ;
shared_variable_two = 0 ;
}
else
goto RERUN;
}

.......................
.......................
}
The same can be implemented for REL(int *bit_pos, int *address).

These subroutines would then be called through FROTANS subroutines.

I have had thought about using SEMAPHORES but then we had to use 3 semaphores (as in this example) such that operation on one address by one process does not blocks operation on other address which is being accessed by multiple process.

Thanks in advance.

Last edited by S.P.Prasad; 05-03-2004 at 03:34 AM..
 
mlockall(3)						     Library Functions Manual						       mlockall(3)

NAME
mlockall, munlockall - Locks into memory, or unlocks, all of a specified process's pages (P1003.1b) LIBRARY
Realtime Library (librt.so, librt.a) SYNOPSIS
#include <sys/mman.h> int mlockall ( int flags); int munlockall (void); PARAMETERS
flags Determines whether the pages to be locked are those currently mapped by the process's address space, those that will be mapped in the future, or both. The flags argument is constructed as the OR of one or more of the constants, MCL_CURRENT or MCL_FUTURE, as defined in the <mman.h> header file. DESCRIPTION
The mlockall function causes all of the pages mapped by the process's address space to be memory resident until unlocked by a call to the munlockall function, until the process exits, or until the process calls exec. MCL_CURRENT locks all of the pages currently mapped into the process's address space. MCL_FUTURE locks all of the pages that become mapped into the process's address space in the future, when those mappings are established. You can specify MCL_CURRENT and subsequently specify MCL_FUTURE to lock both current and future address space. The munlockall function unlocks all currently mapped pages of the process's address space. Any pages that become mapped into a process's address space after a call to munlockall are not locked unless otherwise specified by a subsequent call to mlockall. Pages locked or mapped into another process's address space are unaffected by this process's call to the munlockall function. Locking the process's pages into memory also makes the process unswappable. When the pages are unlocked, the process is made swappable. A lock is not inherited across a fork. All memory locks established on an address by this process are removed if an address range associ- ated with the lock is unmapped with a call to the munmap function. You must have superuser privileges to call the mlockall function. RETURN VALUES
On a successful call to the mlockall function, a value of 0 (zero) is returned and memory is locked. On an unsuccessful call, a value of -1 is returned, no memory is locked, and errno is set to indicate that an error occurred. On a successful call to the munlockall function, a value of 0 (zero) is returned and memory is unlocked. On an unsuccessful call, a value of -1 is returned and errno is set to indicate that an error occurred. ERRORS
The mlockall and munlockall functions fail under the following condition: [ENOSYS] The implementation does not support this memory locking interface. If any of the following conditions occur, the mlockall function fails: [EAGAIN] Some or all of the memory identified by the operation could not be locked when the call was made. [EINVAL] The flags argument is zero or includes unimplemented flags. [ENOMEM] Locking all of the pages currently mapped into the process's address space exceeds an implementation-defined limit on the amount of memory that the process may lock. [EPERM] The calling process does not have the appropriate privilege to perform the requested operation. RELATED INFORMATION
Functions: exec(2), _exit(2), fork(2), munmap(2) Guide to Realtime Programming delim off mlockall(3)
All times are GMT -4. The time now is 03:37 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy