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..
 
ppmtosixel(1)						      General Commands Manual						     ppmtosixel(1)

NAME
ppmtosixel - convert a portable pixmap into DEC sixel format SYNOPSIS
ppmtosixel [-raw] [-margin] [ppmfile] DESCRIPTION
Reads a portable pixmap as input. Produces sixel commands (SIX) as output. The output is formatted for color printing, e.g. for a DEC LJ250 color inkjet printer. If RGB values from the PPM file do not have maxval=100, the RGB values are rescaled. A printer control header and a color assignment table begin the SIX file. Image data is written in a compressed format by default. A printer control footer ends the image file. OPTIONS
-raw If specified, each pixel will be explicitly described in the image file. If -raw is not specified, output will default to com- pressed format in which identical adjacent pixels are replaced by "repeat pixel" commands. A raw file is often an order of magni- tude larger than a compressed file and prints much slower. -margin If -margin is not specified, the image will be start at the left margin (of the window, paper, or whatever). If -margin is speci- fied, a 1.5 inch left margin will offset the image. PRINTING
Generally, sixel files must reach the printer unfiltered. Use the lpr -x option or cat filename > /dev/tty0?. BUGS
Upon rescaling, truncation of the least significant bits of RGB values may result in poor color conversion. If the original PPM maxval was greater than 100, rescaling also reduces the image depth. While the actual RGB values from the ppm file are more or less retained, the color palette of the LJ250 may not match the colors on your screen. This seems to be a printer limitation. SEE ALSO
ppm(5) AUTHOR
Copyright (C) 1991 by Rick Vinci. 26 April 1991 ppmtosixel(1)
All times are GMT -4. The time now is 12:59 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy