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(2)							System Calls Manual						       mlockall(2)

NAME
mlockall() - lock a process virtual address space in memory SYNOPSIS
DESCRIPTION
The system call allows the calling process to lock its entire virtual address space into memory, making it immune to all routine swapping. flags may be one or both of the following: Lock the current process virtual address space. All addressable pages of the address space are locked. Lock any future additions to the process virtual address space. Note that does not imply or can be used to unlock all or a portion of the address space locked with A single call to removes all locks from the process virtual address space. An call results in only the specified pages being unlocked. Regardless of how many times a process locks a page, a single or will unlock it. When memory is shared by multiple processes and mlocks are applied to the same physical page by multiple processes, a page remains locked until the last lock is removed from that page. Locks and applied with are not inherited by a child process. The user must have the privilege. Although and the family of functions may be used together in an application, each may affect the other in unexpected ways. This practice is not recommended. Security Restrictions Some or all of the actions associated with this system call require the privilege. Processes owned by the superuser have this privilege. Processes owned by other users may have this privilege, depending on system configuration. See privileges(5) for more information about privileged access on systems that support fine-grained privileges. RETURN VALUE
returns the following values: Successful completion. Failure. The requested operation is not performed. is set to indicate the error. ERRORS
If fails, is set to one of the following values: The flags field did not contain either and/or There is not enough lockable memory in the system to satisfy the locking request. The user does not have the privilege. EXAMPLES
The following call to locks the entire process virtual address space in memory and ensures that any future additions to the address space will also be locked in memory: SEE ALSO
setprivgrp(1M), getprivgrp(2), mlock(2), munlock(2), munlockall(2), plock(2), privileges(5). STANDARDS CONFORMANCE
mlockall(2)
All times are GMT -4. The time now is 11:41 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy