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 REDHAT

ld.so

ld.so(8)						      System Manager's Manual							  ld.so(8)

NAME

       ld.so, ld-linux.so* - dynamic linker/loader

DESCRIPTION

       ld.so  loads  the shared libraries needed by a program, prepares the program to run, and then runs it.  Unless explicitly specified via the
       -static option to ld during compilation, all Linux programs are incomplete and require further linking at run time.

       The necessary shared libraries needed by the program are searched for in the following order

       o      Using the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist.

       o      Using the environment variable LD_LIBRARY_PATH .	Except if the executable is a setuid/setgid binary, in which case it is ignored.

       o      Using the DT_RUNPATH dynamic section attribute of the binary if present.

       o      From the cache file /etc/ld.so.cache which contains a compiled list of candidate libraries previously found in the augmented library
	      path. If, however, the binary was linked with -z nodeflib linker option, libraries in the default library paths are skipped.

       o      In the default path /lib, and then /usr/lib.  If the binary was linked with -z nodeflib linker option, this step is skipped.

SYNOPSIS

       The  dynamic  linker can be run either indirectly through running some dynamically linked program or library (in which case no command line
       options to the dynamic linker can be passed and the dynamic linker which is stored in the .interp section of the program  is  executed)	or
       directly by running:

       /lib/ld-linux.so.*  [OPTIONS] [PROGRAM [ARGUMENTS]]

COMMAND LINE OPTIONS

       --list List all dependencies and how they are resolved.

       --verify
	      Verify that program is dynamically linked and this dynamic linker can handle it.

       --library-path PATH
	      Override LD_LIBRARY_PATH environment variable setting (see below).

       --ignore-rpath LIST
	      Ignore RPATH and RUNPATH information in object names in LIST.

ENVIRONMENT

       LD_LIBRARY_PATH
	      A colon-separated list of directories in which to search for ELF libraries at execution-time.  Similar to the PATH environment vari-
	      able.

       LD_PRELOAD
	      A whitespace-separated list of additional, user-specified, ELF shared libraries to be loaded before all others.  This can be used to
	      selectively  override  functions	in  other shared libraries.  For setuid/setgid ELF binaries, only libraries in the standard search
	      directories that are also setuid will be loaded.

       LD_TRACE_LOADED_OBJECTS
	      If set to non-empty string, causes the program to list its dynamic library dependencies, as if run by ldd, instead of  running  nor-
	      mally.

       LD_BIND_NOW
	      If  set  to non-empty string, causes the dynamic linker to resolve all symbols at program startup instead of deferring function call
	      resolval to the point when they are first referenced.

       LD_WARN
	      If set to non-empty string, warn about unresolved symbols.

       LD_DEBUG
	      Output verbose debugging information about the dynamic linker.  If set to all prints all debugging information it  has,  if  set	to
	      help prints a help message about which categories can be specified in this environment variable.

       LD_DEBUG_OUTPUT
	      File where LD_DEBUG output should be fed into, default is standard output. LD_DEBUG_OUTPUT is ignored for setuid/setgid binaries.

       LD_VERBOSE
	      If  set  to  non-empty string, output symbol versioning information about the program if querying information about the program (ie.
	      either LD_TRACE_LOADED_OBJECTS has been set, or --list or --verify options have been given to the dynamic linker).

FILES

       /lib/ld-linux.so.*  ELF dynamic linker/loader
       /etc/ld.so.cache
	      File containing a compiled list of directories in which to search for libraries and an ordered list of candidate libraries.
       /etc/ld.so.preload
	      File containing a whitespace separated list of ELF shared libraries to be loaded before the program.  libraries and an ordered  list
	      of candidate libraries.
       lib*.so*
	      shared libraries

SEE ALSO

       ldd(1), ldconfig(8).

AUTHORS

       Roland McGrath, Ulrich Drepper and others.  This man page is derived from libc 5 ld.so manual page.

								  30 October 2000							  ld.so(8)