Atomicity Post: 50847

Sponsored Content

Top Forums Programming Atomicity Post 50847 by S.P.Prasad on Tuesday 4th of May 2004 07:53:17 AM

05-04-2004

Registered User

Thanks for the information, Driver.

Quote:

Process 2 now gets to execute, finds the shared variable zero too and writes its PID to it. Then process 1 gets to execute again and overwrites the PID of the other process.

The second if takes care such that only one process has the right to execute code:

Quote:

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 ;
}

I hope that I am clear.

Quote:

I'm now sure why shared libraries come into play now ...

Shared libraries (also called dynamic libraries) are linked into the program in two stages. First, during compile time, the linker verifies that all the symbols (again, functions, variables and the like) required by the program, are either linked into the program, or in one of its shared libraries. However, the object files from the dynamic library are not inserted into the executable file. Instead, when the program is started, a program in the system (called a dynamic loader) checks out which shared libraries were linked with the program, loads them to memory, and attaches them to the copy of the program in memory.

The complex phase of dynamic loading makes launching the program slightly slower, but this is a very insignificant drawback, that is out-weighted by a great advantage - if a second program linked with the same shared library is executed, it can use the same copy of the shared library, thus saving a lot of memory. Only one copy of the library is stored in memory at any given time. This means we can use far less memory to run our programs, and the executable files are much smaller, thus saving a lot of disk space as well.

Hence if I write LOCK() and REL() subroutines as a part of Shared Library and link it to the executable, will not aid me to make the operations atomic. I can easily validate in the subroutines which address is requested for locking and which for release.

Thanks in advance.

I personally thank Driver and Perderabo for their interest shown to solve the issue. Please continue aiding me till we conclude to a unanimous decision.

S.P.Prasad

View Public Profile for S.P.Prasad

Find all posts by S.P.Prasad

LEARN ABOUT CENTOS

execstack

execstack(8)						      System Manager's Manual						      execstack(8)

NAME

       execstack - tool to set, clear, or query executable stack flag of ELF binaries and shared libraries

SYNOPSIS

       execstack [OPTION...] [FILES]

DESCRIPTION

       execstack  is  a  program which sets, clears, or queries executable stack flag of ELF binaries and shared libraries.  Linux has in the past
       allowed execution of instructions on the stack and there are lots of binaries and shared libraries assuming this  behaviour.   Furthermore,
       GCC  trampoline	code  for  e.g.  nested  functions requires executable stack on many architectures.  To avoid breaking binaries and shared
       libraries which need executable stack, ELF binaries and shared libraries now can be marked as requiring executable stack or  not  requiring
       it.  This marking is done through the p_flags field in the PT_GNU_STACK program header entry.  If the marking is missing, kernel or dynamic
       linker need to assume it might need executable stack.  The marking is done automatically by recent GCC versions (objects using  trampolines
       on  the	stack  are marked as requiring executable stack, all other newly built objects are marked as not requiring it) and linker collects
       these markings into marking of the whole binary or shared library.  The user can override this at assembly  time  (through  --execstack	or
       --noexecstack assembler options), at link time (through -z execstack or -z noexecstack linker options) and using the execstack tool also on
       an already linker binary or shared library.  This tool is especially useful for third party shared libraries where it is  known	that  they
       don't need executable stack or testing proves it.

OPTIONS

       -s --set-execstack
	      Mark binary or shared library as requiring executable stack.

       -c --clear-execstack
	      Mark binary or shared library as not requiring executable stack.

       -q --query
	      Query  executable  stack	marking  of  binaries and shared libraries.  For each file it prints either - when executable stack is not
	      required, X when executable stack is required or ?  when it is unknown whether the object requires  or  doesn't  require	executable
	      stack (the marking is missing).

       -V     Print execstack version and exit.

       -? --help
	      Print help message.

       --usage
	      Print a short usage message.

ARGUMENTS

       Command line arguments should be names of ELF binaries and shared libraries which should be modified or queried.

EXAMPLES

	      # execstack -s ~/lib/libfoo.so.1
       will mark ~/lib/libfoo.so.1 as requiring executable stack.
	      # execstack -c ~/bin/bar
       will mark ~/bin/bar as not requiring executable stack.
	      # execstack -q ~/lib/libfoo.so.1 ~/bin/bar
       will query executable stack marking of the given files.

SEE ALSO

       ld.so(8).

BUGS

       execstack  doesn't  support yet marking of executables if they do not have PT_GNU_STACK program header entry nor they have room for program
       segment header table growth.

AUTHORS

       Jakub Jelinek <jakub@redhat.com>.

								  28 October 2003						      execstack(8)