How to create a shareable image on IA64 using Pascal - VMS

This is a discussion on How to create a shareable image on IA64 using Pascal - VMS ; Hi, Does anyone have a quick example of how to create a shareable image using Pascal on IA64 (or please correct the code below). It is intended that this image, when installed with /open/header/share/write, will be used simply as a ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: How to create a shareable image on IA64 using Pascal

  1. How to create a shareable image on IA64 using Pascal

    Hi,

    Does anyone have a quick example of how to create a shareable image using
    Pascal on IA64 (or please correct the code below). It is intended that this
    image, when installed with /open/header/share/write, will be used simply as
    a data repository for other applications which are linked together with it.
    All the examples I have seen in the documentation refer to shared memory
    between linked object files rather than against a shareable image. Any help
    you can give me would be greatly appreciated.

    Regards,

    Adrian Birkett




    My example:

    $ edit common.pas
    { potential common storage module }
    [environment ('common')]
    module common;
    type
    common_r = record
    my_int : integer;
    my_str : varying [10] of char;
    end;
    end.

    $ pascal common.pas
    $ link common/share
    $ install add/open/head/share/write disk1:[dir]common.exe
    $ define common disk1:[dir]common.exe

    $ edit prog1.pas
    {simple data writer program}
    [inherit ('disk1:[dir]common')]

    program prog1(input output);
    var common:[common]common_r;
    begin
    common.my_int := 1000;
    common.my_str := 'Hello';
    end.

    $ pascal/debug/nooptim prog1
    $ link prog1, sys$input/opt
    disk1:[dir]common.exe/share
    $ run prog1 !step through to end

    [in a different process]

    $ edit prog2.pas
    {simple data reader}
    [inherit ('disk1:[dir]common')]

    program prog2(input output);
    var common:[common]common_r;
    begin
    writeln('int = ', common.my_int);
    writeln('str = ', common.my_str);
    end.

    $ pascal/debug/nooptim prog2
    $ link prog2, sys$input/opt
    disk1:[dir]common.exe/share
    $ run prog2 !noting that prog1 is still running in your other process
    int = 0
    str =



  2. Re: How to create a shareable image on IA64 using Pascal

    In article , "Ade" writes:
    >Hi,
    >
    >Does anyone have a quick example of how to create a shareable image using
    >Pascal on IA64 (or please correct the code below). It is intended that this
    >image, when installed with /open/header/share/write, will be used simply as
    >a data repository for other applications which are linked together with it.
    >All the examples I have seen in the documentation refer to shared memory
    >between linked object files rather than against a shareable image. Any help
    >you can give me would be greatly appreciated.
    >
    >Regards,
    >
    >Adrian Birkett


    Take a look in the linker documentation and, specifically, at the linker
    options. You will need to declare your data in the linker option file.
    I'm not sure you're going to be able to share data using the Pascal mech-
    anism you've show herein. I'll leave that to John Reagan resident Pascal
    d00d for comment.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  3. Re: How to create a shareable image on IA64 using Pascal

    Hi,

    Thanks for the quick response, I'll dig the said manual out and have a look.

    Regards,

    Ade



  4. Re: How to create a shareable image on IA64 using Pascal

    Your 'common' program does nothing.
    It just declares a record layout but does not allocate on.
    Do a PASCAL/LIST ... no PSECT create.
    Do a LINK/MAP (Always... when creating a shareable!!! )... nothing.

    I know nothing about pascal, but would guess you need to at least add:

    var
    test : [ COMMON(my_test_psect) ] common_r;

    And when you study chapter 4 in the Linker manual you will see you
    need a .OPT file with at least something like:

    symbol_vector=(MY_TEST_PSECT=psect)

    The link command then becomes:

    $link/sha/map common,common/opt

    Hint: use a logical name DIFFERENT from any module/image name.

    Good luck!
    Hein.











  5. Re: How to create a shareable image on IA64 using Pascal

    On Oct 6, 5:42 am, "Ade" wrote:
    > Hi,
    >
    > Does anyone have a quick example of how to create a shareable image using
    > Pascal on IA64 (or please correct the code below). It is intended that this
    > image, when installed with /open/header/share/write, will be used simply as
    > a data repository for other applications which are linked together with it.
    > All the examples I have seen in the documentation refer to shared memory
    > between linked object files rather than against a shareable image. Any help
    > you can give me would be greatly appreciated.
    >
    > Regards,
    >
    > Adrian Birkett
    >
    > My example:
    >
    > $ edit common.pas
    > { potential common storage module }
    > [environment ('common')]
    > module common;
    > type
    > common_r = record
    > my_int : integer;
    > my_str : varying [10] of char;
    > end;
    > end.
    >
    > $ pascal common.pas
    > $ link common/share
    > $ install add/open/head/share/write disk1:[dir]common.exe
    > $ define common disk1:[dir]common.exe
    >
    > $ edit prog1.pas
    > {simple data writer program}
    > [inherit ('disk1:[dir]common')]
    >
    > program prog1(input output);
    > var common:[common]common_r;
    > begin
    > common.my_int := 1000;
    > common.my_str := 'Hello';
    > end.
    >
    > $ pascal/debug/nooptim prog1
    > $ link prog1, sys$input/opt
    > disk1:[dir]common.exe/share
    > $ run prog1 !step through to end
    >
    > [in a different process]
    >
    > $ edit prog2.pas
    > {simple data reader}
    > [inherit ('disk1:[dir]common')]
    >
    > program prog2(input output);
    > var common:[common]common_r;
    > begin
    > writeln('int = ', common.my_int);
    > writeln('str = ', common.my_str);
    > end.
    >
    > $ pascal/debug/nooptim prog2
    > $ link prog2, sys$input/opt
    > disk1:[dir]common.exe/share
    > $ run prog2 !noting that prog1 is still running in your other process
    > int = 0
    > str =


    Ade,

    The procedures are essentially the same as they are on Alpha (the
    procedures for VAX are slightly different).

    I can point to my presentation " OpenVMS Shareable Libraries: An
    Implementor's Guide" from the 2000 Compaq Enterprise Technology
    Symposium in Los Angeles at http://www.rlgsc.com/cets/2000/460.html

    If I recall correctly, Hoff has also published some material on this
    topic.

    - Bob Gezelter, http://www.rlgsc.com

  6. Re: How to create a shareable image on IA64 using Pascal

    In article , "Ade" writes:
    > Hi,
    >
    > Does anyone have a quick example of how to create a shareable image using
    > Pascal on IA64 (or please correct the code below). It is intended that this
    > image, when installed with /open/header/share/write, will be used simply as
    > a data repository for other applications which are linked together with it.
    > All the examples I have seen in the documentation refer to shared memory
    > between linked object files rather than against a shareable image. Any help
    > you can give me would be greatly appreciated.


    Having used both shared images and shared memory sections to store
    data, I would advise quite strongly against the former.

    Anyone can set up a shared memory section. Only a user with CMKRNL
    can install a shared image, which is required if it is used for
    data storage (has writeable shareable psects). This simple issue
    makes a big difference if there are cases when the user needs to start
    up or shut down the application.

    If you do use shared images, make sure you control the matching
    criteria via linker options. The default criteria is an exact match
    to a timestamp made when the share dimage is built, this is often
    not what you need.

    We dealt with other issues on older versions of VMS that are no
    longer an issue, but I still reguard the CMKRNL issue a sufficient
    cause to avoid shared images.

    We had so many problems with these on one of three major systems
    I worked with that I looked into the other two and found out this
    was exactly how the other two worked with no one even knowing they
    had shareable writeable sections. I personnaly sat down and recoded
    those parts of the first major system to get rid of these problems.


  7. Re: How to create a shareable image on IA64 using Pascal


    Thanks to all who have responed thus far.

    My definition code now looks like:
    [environment ('shared')]
    module shared_memory;

    type
    shared_r = record
    my_int : integer;
    my_str : varying [10] of char;
    end;

    var
    shared_mem : [GLOBAL,VOLATILE,COMMON(shared_psect)] shared_r;

    end.

    I have tried to research the LINK command and have modified the command to
    be:

    $ LINK/MAP/FULL/SHARE common, sys$input/opt
    symbol_vector=(shared_mem=data, shared_psect=psect)


    However, looking in the map, the defined psect (shared_psect) has the NOSHR
    flag on it. This must be something simple that I am overlooking. Has anybody
    some more suggestions please.

    Thanks,

    Ade



  8. Re: How to create a shareable image on IA64 using Pascal


    > However, looking in the map, the defined psect (shared_psect) has the NOSHR
    > flag on it. This must be something simple that I am overlooking.


    So change that!... with an other linker option, or an other Pascal
    attribute (Carefully check Language Reference Manual and User Guide)


    > Has anybody some more suggestions please.


    1) Heed Bob's advice.
    Skip the installed common if you can go straight to CMPSC.

    2) Be sure to INHERIT those record/common definitions.
    Use Pascal Environment files (.PEN) and such!

    Cheers,
    Hein.

  9. Re: How to create a shareable image on IA64 using Pascal


    "Ade" wrote in message
    newsDpGk.35367$qg2.11237@newsfe30.ams2...
    >
    > Thanks to all who have responed thus far.
    >
    > var
    > shared_mem : [GLOBAL,VOLATILE,COMMON(shared_psect)] shared_r;


    VOLATILE, COMMON should be sufficient.


    >
    > $ LINK/MAP/FULL/SHARE common, sys$input/opt
    > symbol_vector=(shared_mem=data, shared_psect=psect)
    >
    >
    > However, looking in the map, the defined psect (shared_psect) has the
    > NOSHR flag on it. This must be something simple that I am overlooking. Has
    > anybody some more suggestions please.
    >


    I've never used symbol_vectors for share common myself.

    And, yes, reset the psect attribute to SHR in the options file.

    John



  10. Re: How to create a shareable image on IA64 using Pascal


    "Hein RMS van den Heuvel" wrote in message
    news:a76fd537-5127-4b0e-8cb7-db8d96875b50@t54g2000hsg.googlegroups.com...
    >
    >> However, looking in the map, the defined psect (shared_psect) has the
    >> NOSHR
    >> flag on it. This must be something simple that I am overlooking.

    >
    > So change that!... with an other linker option, or an other Pascal
    > attribute (Carefully check Language Reference Manual and User Guide)
    >
    >
    >> Has anybody some more suggestions please.

    >
    > 1) Heed Bob's advice.
    > Skip the installed common if you can go straight to CMPSC.
    >
    > 2) Be sure to INHERIT those record/common definitions.
    > Use Pascal Environment files (.PEN) and such!
    >
    > Cheers,
    > Hein.


    Ok, I have now included a PSECT_ATTRIBUTE=shared_psect=SHR,GBL,NOEXE in the
    link procedure. All well and good, however, I now get conflicting attributes
    for section shared_psect when I try to link my PROG1 (see original post).

    I know I'm being a pain and I apologize, but I really need to understand
    this

    Thanks again,

    Ade



  11. Re: How to create a shareable image on IA64 using Pascal

    Typo in the above:

    Should read:

    .... PSECT_ATTRIBUTE=shared_psect,SHR,GBL,NOEXE

    Ade



  12. Re: How to create a shareable image on IA64 using Pascal

    Hi Ade,

    > Ok, I have now included a PSECT_ATTRIBUTE=shared_psect=SHR,GBL,NOEXE in

    the
    > link procedure. All well and good, however, I now get conflicting

    attributes
    > for section shared_psect when I try to link my PROG1 (see original post).


    Youe need to make that modification when linking *all* or in your case
    *both* images (ie the Shareable data common) and the images that will link
    to it. Otherwise look at the listings and see which attributes are different
    in each object.

    The PSECT attr default changed from SHR to NOSHR when we went from VAX to
    Alpha. Please also be aware that part of some language calling standard
    means that your PSECTs will be rounded to multiples of 8 bytes. Which is
    peachy except the MACRO compiler is not restricted by this standard so you
    may have to put your own padding bytes at the end.

    Cheers Richard Maher

    "Ade" wrote in message
    news:WIrGk.7628$8r6.5333@newsfe03.ams2...
    >
    > "Hein RMS van den Heuvel" wrote in message
    > news:a76fd537-5127-4b0e-8cb7-db8d96875b50@t54g2000hsg.googlegroups.com...
    > >
    > >> However, looking in the map, the defined psect (shared_psect) has the
    > >> NOSHR
    > >> flag on it. This must be something simple that I am overlooking.

    > >
    > > So change that!... with an other linker option, or an other Pascal
    > > attribute (Carefully check Language Reference Manual and User Guide)
    > >
    > >
    > >> Has anybody some more suggestions please.

    > >
    > > 1) Heed Bob's advice.
    > > Skip the installed common if you can go straight to CMPSC.
    > >
    > > 2) Be sure to INHERIT those record/common definitions.
    > > Use Pascal Environment files (.PEN) and such!
    > >
    > > Cheers,
    > > Hein.

    >
    > Ok, I have now included a PSECT_ATTRIBUTE=shared_psect=SHR,GBL,NOEXE in

    the
    > link procedure. All well and good, however, I now get conflicting

    attributes
    > for section shared_psect when I try to link my PROG1 (see original post).
    >
    > I know I'm being a pain and I apologize, but I really need to understand
    > this
    >
    > Thanks again,
    >
    > Ade
    >
    >




  13. Re: How to create a shareable image on IA64 using Pascal

    On Oct 6, 6:42*am, "Ade" wrote:
    > Hi,
    >
    > Does anyone have a quick example of how to create a shareable image using
    > Pascal on IA64 (or please correct the code below). It is intended that this
    > image, when installed with /open/header/share/write, *will be used simply as
    > a data repository for other applications which are linked together with it.
    > All the examples I have seen in the documentation refer to shared memory
    > between linked object files rather than against a shareable image. Any help
    > you can give me would be greatly appreciated.
    >
    > Regards,
    >
    > Adrian Birkett
    >
    > My example:
    >
    > $ edit common.pas
    > { potential common storage module }
    > [environment ('common')]
    > module common;
    > type
    > * * common_r = record
    > * * * * my_int : integer;
    > * * * * my_str : varying [10] of char;
    > * * end;
    > end.
    >
    > $ pascal common.pas
    > $ link common/share
    > $ install add/open/head/share/write disk1:[dir]common.exe
    > $ define common disk1:[dir]common.exe
    >
    > $ edit prog1.pas
    > {simple data writer program}
    > [inherit ('disk1:[dir]common')]
    >
    > program prog1(input output);
    > var * *common:[common]common_r;
    > begin
    > * * common.my_int := 1000;
    > * * common.my_str := 'Hello';
    > end.
    >
    > $ pascal/debug/nooptim prog1
    > $ link prog1, sys$input/opt
    > disk1:[dir]common.exe/share
    > $ run prog1 !step through to end
    >
    > [in a different process]
    >
    > $ edit prog2.pas
    > {simple data reader}
    > [inherit ('disk1:[dir]common')]
    >
    > program prog2(input output);
    > var * *common:[common]common_r;
    > begin
    > * * writeln('int = ', common.my_int);
    > * * writeln('str = ', common.my_str);
    > end.
    >
    > $ pascal/debug/nooptim prog2
    > $ link prog2, sys$input/opt
    > disk1:[dir]common.exe/share
    > $ run prog2 * * * *!noting that prog1 is still running in your other process
    > int = * * * * 0
    > str =


    Adrian,

    [SET SOAPBOX/SAVE]
    [SET SOAPBOX/MODERATE]

    I read things a little TOO quickly yesterday morning (here in New York
    City).

    I strongly recommend AGAINST using shareable storage between processes
    for data storage. The perceived performance benefits are not
    significant in the overwhelming majority of cases. The hazards of
    improper synchronization are far more disruptive and damaging. I have
    troubleshot many truly bizarre problems caused by nothing more
    egregious than the "performance" improvement cited by using shared
    memory.

    On the other hand, I have used intra-node DECnet logical links to
    query a server process for information in a far safer fashion.
    Admittedly, it is not as theoretically efficient, but in the scheme of
    things, it is not measurable in most cases. This is even more true
    today than it was 25 years ago. For most purposes, the substantially
    extra effort to design, implement, and qualify shared memory code is
    simply unjustified by the overall performance impact on the system.

    In short, if one is designing the OpenVMS file system, it is worth the
    effort. If one is maintaining applications data, it is far, far easier
    to debug a DECnet logical link-based reference monitor (which is
    straightforward to instrument) than to debug a collection of processes
    accessing a shared region. The increase in complexity is quite often
    exponential, for negligible increases in "efficiency". This is
    particularly true on today's multicore and multithread processors.

    For static data, consider the use of an applications specific logical
    name table, perhaps maintained by a control process and readable by
    designated other processes.

    DECnet logical links are also preferable to mailboxes, as they have
    the inherent ability to synchronize BOTH sides of the connection. The
    loss of either process is automatically reported to its correspondent,
    allowing appropriate action to be taken. This is far more subtle with
    mailboxes.

    [SET SOAPBOX/RESTORE]

    - Bob Gezelter, http://www.rlgsc.com

  14. Re: How to create a shareable image on IA64 using Pascal

    On Oct 7, 7:30*am, "Ade" wrote:
    > Unfortunately, you guessed it, the
    > system uses common shared memory for data storage and re-writing this for
    > any other method is completely out of the question.


    My experience with Pascal has become extraordinarily rusty so I won't
    be of much help on syntax. However, I suspect the conversion from a
    shared image to a mapped memory section isn't as complex as you might
    think.

    Without much investigation, there would be three steps that I can
    think of, which have to be applied to all applications that are
    sharing the memory space:

    a) Define the record structure in a COMMON psect. I don't remember
    the Pascal equivalent, but I'm sure it's trivial.

    b) At the very beginning of each application insert a call to an
    external subroutine that invokes the SYS$CRMPSC system service. You
    have to calculate the number of pages being used by the data psect,
    and for that (on Alpha) you need to get the size of a page on the host
    system.

    c) Modify the linker options file to force the COMMON psect into its
    own address space. On Alpha the option was /SOLITARY. I haven't
    looked into the I64 equivalent, if it's not the exactly the same.

    From that point on the applications should behave the same.

    > The common memory of
    > just one of the seven shareable images in this suite contains over a quarter
    > mb of non-static real-time data.


    The wonderful thing about virtual memory is that it's virtual. I
    recently worked on an application which had a 4mb mapped global
    section which contains dynamic data updated by four cooperating
    processes. You might need to play with PGFLQUO but otherwise 1/4 mb
    of shared address space shouldn't be much of a concern.

  15. Re: How to create a shareable image on IA64 using Pascal

    Hi,

    My problem seems to be solved (for now).

    I simply removed the additional definitions of 'shared_memory' and
    referenced the area of 'shared_mem' as defined in the common programs' data
    area. After realising what I was doing, I gave myself a real good kicking.
    It should have been obvious.

    I've gone a bit overboard on the link options but it now works OK. For those
    wanting to see my solution, I have included the code below.

    Thanks to everyone for your help and suggestions.

    Ade



    {shared memory module}
    [environment ('shared')]
    module shared_memory;

    type
    shared_r = record
    my_int : integer;
    my_str : varying [10] of char;
    end;

    shared_mem : [global, common(shared_psect)] shared_r;

    end.

    $ instal remove disk1:[dir]common.exe
    $ pascal/align=vax common.pas
    $ link/map/full/share/gst common, sys$input/opt
    case_sensitive=no
    symbol_table=global
    gsmatch=lequal,1,10000
    symbol_vector=(shared_mem=data, shared_psect=psect)
    psect_attributes=shared_psect,shr,gbl,noexe,wrt
    $ define/nolog common disk1:[dir]common.exe
    $ instal add /open/head/share/write/resident common


    {prog1 - writes to common memory}
    [inherit ('disk1:[dir]shared')]

    program prog1(input, output);

    begin
    shared_mem.my_int := 1000;
    shared_mem.my_str := 'Hello';
    writeln ('int = ',shared_mem.my_int);
    writeln ('str = ',shared_mem.my_str);
    end.

    $ pascal/align=vax prog1
    $ link /map/full prog1, sys$input/opt
    disk1:[dir]common.exe/share
    psect_attributes=shared_psect,shr,gbl,noexe,wrt

    {prog2 - reads common memory}
    [inherit ('disk1:[dir]shared')]

    program prog2(input, output);

    begin
    writeln ('int = ',shared_mem.my_int);
    writeln ('str = ',shared_mem.my_str);
    end.

    $ pascal/align=vax prog2
    $ link /map/full prog2, sys$input/opt
    disk1:[dir]common.exe/share
    psect_attributes=shared_psect,shr,gbl,noexe,wrt


    $ run prog2 !<-- check contents before
    int = 0
    str =

    $ run prog1 !<-- populate
    int = 1000
    str = Hello

    $ run prog2 !<-- check contents after
    int = 1000
    str = Hello

    Easy when you know how 8-)

    Ade



  16. Re: How to create a shareable image on IA64 using Pascal

    Hi Adrian,

    (Not so much for your benefit as for aothers that may be reading here)

    Please do not listen to the incompetent filfth that have responded here!
    Heaven forbid that VMS has to contend with the "Can't handle shared memory
    slur" on top of everything else :-(

    There is nothing wrong with "COMMON" areas and shared PSECTs! Tell the usual
    suspects to "you know what"!

    OOh! Global Sections are spooky; leave them to Unix! What about Cache
    Fusion? What about an operating system that offers functionality? Global
    Sections "a bridge too far"?

    You all make me sick!

    Regards Richard Maher


    "Ade" wrote in message
    news:rYlGk.35222$0D6.20078@newsfe01.ams2...
    > Hi,
    >
    > Does anyone have a quick example of how to create a shareable image using
    > Pascal on IA64 (or please correct the code below). It is intended that

    this
    > image, when installed with /open/header/share/write, will be used simply

    as
    > a data repository for other applications which are linked together with

    it.
    > All the examples I have seen in the documentation refer to shared memory
    > between linked object files rather than against a shareable image. Any

    help
    > you can give me would be greatly appreciated.
    >
    > Regards,
    >
    > Adrian Birkett
    >
    >
    >
    >
    > My example:
    >
    > $ edit common.pas
    > { potential common storage module }
    > [environment ('common')]
    > module common;
    > type
    > common_r = record
    > my_int : integer;
    > my_str : varying [10] of char;
    > end;
    > end.
    >
    > $ pascal common.pas
    > $ link common/share
    > $ install add/open/head/share/write disk1:[dir]common.exe
    > $ define common disk1:[dir]common.exe
    >
    > $ edit prog1.pas
    > {simple data writer program}
    > [inherit ('disk1:[dir]common')]
    >
    > program prog1(input output);
    > var common:[common]common_r;
    > begin
    > common.my_int := 1000;
    > common.my_str := 'Hello';
    > end.
    >
    > $ pascal/debug/nooptim prog1
    > $ link prog1, sys$input/opt
    > disk1:[dir]common.exe/share
    > $ run prog1 !step through to end
    >
    > [in a different process]
    >
    > $ edit prog2.pas
    > {simple data reader}
    > [inherit ('disk1:[dir]common')]
    >
    > program prog2(input output);
    > var common:[common]common_r;
    > begin
    > writeln('int = ', common.my_int);
    > writeln('str = ', common.my_str);
    > end.
    >
    > $ pascal/debug/nooptim prog2
    > $ link prog2, sys$input/opt
    > disk1:[dir]common.exe/share
    > $ run prog2 !noting that prog1 is still running in your other

    process
    > int = 0
    > str =
    >
    >




  17. Re: How to create a shareable image on IA64 using Pascal

    On Oct 8, 5:52 am, "Richard Maher"
    wrote:
    > Hi Adrian,
    >
    > (Not so much for your benefit as for aothers that may be reading here)
    >
    > Please do not listen to the incompetent filfth that have responded here!
    > Heaven forbid that VMS has to contend with the "Can't handle shared memory
    > slur" on top of everything else :-(
    >
    > There is nothing wrong with "COMMON" areas and shared PSECTs! Tell the usual
    > suspects to "you know what"!
    >
    > OOh! Global Sections are spooky; leave them to Unix! What about Cache
    > Fusion? What about an operating system that offers functionality? Global
    > Sections "a bridge too far"?
    >
    > You all make me sick!
    >
    > Regards Richard Maher
    >
    > "Ade" wrote in message
    >
    > news:rYlGk.35222$0D6.20078@newsfe01.ams2...
    >
    > > Hi,

    >
    > > Does anyone have a quick example of how to create a shareable image using
    > > Pascal on IA64 (or please correct the code below). It is intended that

    > this
    > > image, when installed with /open/header/share/write, will be used simply

    > as
    > > a data repository for other applications which are linked together with

    > it.
    > > All the examples I have seen in the documentation refer to shared memory
    > > between linked object files rather than against a shareable image. Any

    > help
    > > you can give me would be greatly appreciated.

    >
    > > Regards,

    >
    > > Adrian Birkett

    >
    > > My example:

    >
    > > $ edit common.pas
    > > { potential common storage module }
    > > [environment ('common')]
    > > module common;
    > > type
    > > common_r = record
    > > my_int : integer;
    > > my_str : varying [10] of char;
    > > end;
    > > end.

    >
    > > $ pascal common.pas
    > > $ link common/share
    > > $ install add/open/head/share/write disk1:[dir]common.exe
    > > $ define common disk1:[dir]common.exe

    >
    > > $ edit prog1.pas
    > > {simple data writer program}
    > > [inherit ('disk1:[dir]common')]

    >
    > > program prog1(input output);
    > > var common:[common]common_r;
    > > begin
    > > common.my_int := 1000;
    > > common.my_str := 'Hello';
    > > end.

    >
    > > $ pascal/debug/nooptim prog1
    > > $ link prog1, sys$input/opt
    > > disk1:[dir]common.exe/share
    > > $ run prog1 !step through to end

    >
    > > [in a different process]

    >
    > > $ edit prog2.pas
    > > {simple data reader}
    > > [inherit ('disk1:[dir]common')]

    >
    > > program prog2(input output);
    > > var common:[common]common_r;
    > > begin
    > > writeln('int = ', common.my_int);
    > > writeln('str = ', common.my_str);
    > > end.

    >
    > > $ pascal/debug/nooptim prog2
    > > $ link prog2, sys$input/opt
    > > disk1:[dir]common.exe/share
    > > $ run prog2 !noting that prog1 is still running in your other

    > process
    > > int = 0
    > > str =


    Richard,

    I normally do not respond to comments of this sort, but a
    clarification is in order. As I can read it, none of the posts in this
    thread said "OpenVMS cannot do it". What was said was "In almost all
    cases, this is a dangerous practice".

    I have NEVER claimed that OpenVMS cannot handle shareable storage,
    merely that in my extensive, 30+ year experience, I have seen far move
    (actually, overwhelmingly more) incorrect implementations of shared
    memory management than I have seen correctly done ones.
    Synchronization errors (e.g., race conditions) are devilish difficult
    to identify and eliminate, and virtually impossible to reproduce on
    demand. Avoiding deadlocks and synchronization starvation in complex
    systems is even more difficult.

    Even something as simple as setting switch variable can be fraught
    with hazard. Many programmers who first learned to program using COBOL
    (and indeed, those working in COBOL) use strings to store switch
    values. In one of my AST talks (admittedly multithread -- AST and
    regular; not multiprocessor, which is worse) I reminded attendees that
    the MOVC3 and MOVC5 instructions were interruptable, thus could be
    interrupted by a number of events, including AST delivery. The
    "simple" act of setting changing a switch string from "YES" to "NO "
    could give rise to intermediate values of "YO ", "YE ", "NES", "NOS",
    etc.). Nobody in the audience had considered that possibility
    (admittedly several members of Engineering who heard about my example
    found it amusing). The same thing can happen with inadvertantly mis-
    aligned data. At one conference, someone overheard my discussion of
    that hazard and realized that that was the likely reason why his large
    scale simulation system sporadically produced invalid floating point
    values.

    These problems are exacerbated when the underlying architecture or
    processor is changed, and the timing relationships alter.I have even
    seen situations where a change in the IO configuration caused timing
    issues.

    My overall recommendation is to proceed with EXTREME care. A LINK, or
    a simple test case is far different than multiple processes doing a
    lot of work at high speed. It is all too easy to jump into shared
    memory as a way to avoid complexity and become mired in a quagmire.
    Since I have not seen Adrian's code base, I do not know if this is a
    highly dynamic global area, or a set of read-only parameters. Even a
    set of shared performance counters can become complex.

    If the application is something along the lines of a large scale cache
    (e.g., RMS global buffers, a DBMS, a very high performance system)
    than I would consider the option of global storage, after:
    - the fact of the global storage was hidden behind an API (or at
    least a set of macros)
    - a first implementation of the API was done using a resource monitor
    model (a separate process that implemented the data store)
    - the performance issue was severe enough to justify the extensive
    developer time and review to make sure that the implementation was
    valid and reliable.

    As noted, I had a most entertaining converesation more than a decade
    ago on the implementation of a stock trading message switch where the
    client took exception to not using shared commons (I used DECnet
    logical links, a client subroutine shareable library, and a central
    datalink and server process; in effect a non-privileged device driver/
    ACP model) to implement data link management. They even wanted me to
    guarantee that if the performance was not adequate, I would
    reimplement things at no charge.

    I did the implementation on an Alphastation 3000, and the bottleneck
    was somewhere around 10K transactions/minute. I was limited by the
    trace code (using DECterm) and the link to the trading switch. I
    probably could have gone quite a bit further with a little work. The
    beta went into production without any problems.

    I had a similar experience several years earlier with an application
    that was supposed to support multiple terminals. It was quite a bit
    more cost effective to install the single user image as a shareable
    image than it was to spend man years to work multithreading the
    application. It was also far more resilient.

    Rule 1: Architect allowing the complex solution, but use a less
    complex solution if at all possible. Context switches between
    processes may be costly, but system crashes in the middle of the day,
    are far costlier.

    Thus, my comment that if one is in the applications business, one
    should "Tread with care"

    - Bob Gezelter, http://www.rlgsc.com


  18. Re: How to create a shareable image on IA64 using Pascal

    Hi Bob,

    I've got absolutely nothing against people touting for business in a forum
    like this, and if spreading a bit of FUD around helps drive some anxious or
    insecure customers in your direction them more power to ya! But when
    customers (and anything left that resembles a development community) are put
    off from using VMS for a shared-memory application because "there be
    dragons" or "we use *nix for that" then I've had enough!

    On *nix, and sepcifically with Java, you can find all sorts of documentation
    discussing threading issues and why using wait/notify is now the recommended
    thread synchronization method, plus heaps of discussion *and examples* in
    development forums about performance vs atomicity and mutex granularity. Yet
    on VMS, all one hears is "I wouldn't do that if I were you" or "We know
    something you don't know nah nah nanah nah" :-( If you are really that
    concerned about what can go wrong with a global section application then why
    don't you bring out a Technical Journal article with the "right" way to do
    it? Perhaps a statistics Global Section that is being hammered by hundreds
    of concurrent processes, discussing lighweight locking techniques vs the
    DLM? Incorporate the new Infiniband API for cluster propagation and I'll
    read it myself!

    Otherwise, let it be known, that sharing data between processes via a Global
    Section (whether an installed PSECT or $crmpsc or VLM) is something that has
    been done on VMS since about year dot. Maybe Larry Ellison should agree with
    you and doesn't offer Cache Fusion on VMS? I see this as essential and basic
    functionality that people should be able to receive support for and not the
    usual "As seen at Gezelter labs" or "While I was speaking to Koffee and
    Butrus Butrus the other day at my address to the G7".

    Regards Richard Maher

    "Bob Gezelter" wrote in message
    news:8a3dbb4d-bfc9-433b-ba9f-efa9b3ae84ec@q26g2000prq.googlegroups.com...
    > On Oct 8, 5:52 am, "Richard Maher"
    > wrote:
    > > Hi Adrian,
    > >
    > > (Not so much for your benefit as for aothers that may be reading here)
    > >
    > > Please do not listen to the incompetent filfth that have responded here!
    > > Heaven forbid that VMS has to contend with the "Can't handle shared

    memory
    > > slur" on top of everything else :-(
    > >
    > > There is nothing wrong with "COMMON" areas and shared PSECTs! Tell the

    usual
    > > suspects to "you know what"!
    > >
    > > OOh! Global Sections are spooky; leave them to Unix! What about Cache
    > > Fusion? What about an operating system that offers functionality? Global
    > > Sections "a bridge too far"?
    > >
    > > You all make me sick!
    > >
    > > Regards Richard Maher
    > >
    > > "Ade" wrote in message
    > >
    > > news:rYlGk.35222$0D6.20078@newsfe01.ams2...
    > >
    > > > Hi,

    > >
    > > > Does anyone have a quick example of how to create a shareable image

    using
    > > > Pascal on IA64 (or please correct the code below). It is intended that

    > > this
    > > > image, when installed with /open/header/share/write, will be used

    simply
    > > as
    > > > a data repository for other applications which are linked together

    with
    > > it.
    > > > All the examples I have seen in the documentation refer to shared

    memory
    > > > between linked object files rather than against a shareable image. Any

    > > help
    > > > you can give me would be greatly appreciated.

    > >
    > > > Regards,

    > >
    > > > Adrian Birkett

    > >
    > > > My example:

    > >
    > > > $ edit common.pas
    > > > { potential common storage module }
    > > > [environment ('common')]
    > > > module common;
    > > > type
    > > > common_r = record
    > > > my_int : integer;
    > > > my_str : varying [10] of char;
    > > > end;
    > > > end.

    > >
    > > > $ pascal common.pas
    > > > $ link common/share
    > > > $ install add/open/head/share/write disk1:[dir]common.exe
    > > > $ define common disk1:[dir]common.exe

    > >
    > > > $ edit prog1.pas
    > > > {simple data writer program}
    > > > [inherit ('disk1:[dir]common')]

    > >
    > > > program prog1(input output);
    > > > var common:[common]common_r;
    > > > begin
    > > > common.my_int := 1000;
    > > > common.my_str := 'Hello';
    > > > end.

    > >
    > > > $ pascal/debug/nooptim prog1
    > > > $ link prog1, sys$input/opt
    > > > disk1:[dir]common.exe/share
    > > > $ run prog1 !step through to end

    > >
    > > > [in a different process]

    > >
    > > > $ edit prog2.pas
    > > > {simple data reader}
    > > > [inherit ('disk1:[dir]common')]

    > >
    > > > program prog2(input output);
    > > > var common:[common]common_r;
    > > > begin
    > > > writeln('int = ', common.my_int);
    > > > writeln('str = ', common.my_str);
    > > > end.

    > >
    > > > $ pascal/debug/nooptim prog2
    > > > $ link prog2, sys$input/opt
    > > > disk1:[dir]common.exe/share
    > > > $ run prog2 !noting that prog1 is still running in your other

    > > process
    > > > int = 0
    > > > str =

    >
    > Richard,
    >
    > I normally do not respond to comments of this sort, but a
    > clarification is in order. As I can read it, none of the posts in this
    > thread said "OpenVMS cannot do it". What was said was "In almost all
    > cases, this is a dangerous practice".
    >
    > I have NEVER claimed that OpenVMS cannot handle shareable storage,
    > merely that in my extensive, 30+ year experience, I have seen far move
    > (actually, overwhelmingly more) incorrect implementations of shared
    > memory management than I have seen correctly done ones.
    > Synchronization errors (e.g., race conditions) are devilish difficult
    > to identify and eliminate, and virtually impossible to reproduce on
    > demand. Avoiding deadlocks and synchronization starvation in complex
    > systems is even more difficult.
    >
    > Even something as simple as setting switch variable can be fraught
    > with hazard. Many programmers who first learned to program using COBOL
    > (and indeed, those working in COBOL) use strings to store switch
    > values. In one of my AST talks (admittedly multithread -- AST and
    > regular; not multiprocessor, which is worse) I reminded attendees that
    > the MOVC3 and MOVC5 instructions were interruptable, thus could be
    > interrupted by a number of events, including AST delivery. The
    > "simple" act of setting changing a switch string from "YES" to "NO "
    > could give rise to intermediate values of "YO ", "YE ", "NES", "NOS",
    > etc.). Nobody in the audience had considered that possibility
    > (admittedly several members of Engineering who heard about my example
    > found it amusing). The same thing can happen with inadvertantly mis-
    > aligned data. At one conference, someone overheard my discussion of
    > that hazard and realized that that was the likely reason why his large
    > scale simulation system sporadically produced invalid floating point
    > values.
    >
    > These problems are exacerbated when the underlying architecture or
    > processor is changed, and the timing relationships alter.I have even
    > seen situations where a change in the IO configuration caused timing
    > issues.
    >
    > My overall recommendation is to proceed with EXTREME care. A LINK, or
    > a simple test case is far different than multiple processes doing a
    > lot of work at high speed. It is all too easy to jump into shared
    > memory as a way to avoid complexity and become mired in a quagmire.
    > Since I have not seen Adrian's code base, I do not know if this is a
    > highly dynamic global area, or a set of read-only parameters. Even a
    > set of shared performance counters can become complex.
    >
    > If the application is something along the lines of a large scale cache
    > (e.g., RMS global buffers, a DBMS, a very high performance system)
    > than I would consider the option of global storage, after:
    > - the fact of the global storage was hidden behind an API (or at
    > least a set of macros)
    > - a first implementation of the API was done using a resource monitor
    > model (a separate process that implemented the data store)
    > - the performance issue was severe enough to justify the extensive
    > developer time and review to make sure that the implementation was
    > valid and reliable.
    >
    > As noted, I had a most entertaining converesation more than a decade
    > ago on the implementation of a stock trading message switch where the
    > client took exception to not using shared commons (I used DECnet
    > logical links, a client subroutine shareable library, and a central
    > datalink and server process; in effect a non-privileged device driver/
    > ACP model) to implement data link management. They even wanted me to
    > guarantee that if the performance was not adequate, I would
    > reimplement things at no charge.
    >
    > I did the implementation on an Alphastation 3000, and the bottleneck
    > was somewhere around 10K transactions/minute. I was limited by the
    > trace code (using DECterm) and the link to the trading switch. I
    > probably could have gone quite a bit further with a little work. The
    > beta went into production without any problems.
    >
    > I had a similar experience several years earlier with an application
    > that was supposed to support multiple terminals. It was quite a bit
    > more cost effective to install the single user image as a shareable
    > image than it was to spend man years to work multithreading the
    > application. It was also far more resilient.
    >
    > Rule 1: Architect allowing the complex solution, but use a less
    > complex solution if at all possible. Context switches between
    > processes may be costly, but system crashes in the middle of the day,
    > are far costlier.
    >
    > Thus, my comment that if one is in the applications business, one
    > should "Tread with care"
    >
    > - Bob Gezelter, http://www.rlgsc.com
    >




  19. Re: How to create a shareable image on IA64 using Pascal

    On Oct 12, 5:24*am, "Richard Maher"
    wrote:
    > Hi Bob,
    >
    > I've got absolutely nothing against people touting for business in a forum
    > like this, and if spreading a bit of FUD around helps drive some anxious or
    > insecure customers in your direction them more power to ya! But when
    > customers (and anything left that resembles a development community) are put
    > off from using VMS for a shared-memory application because "there be
    > dragons" or "we use *nix for that" then I've had enough!
    >
    > On *nix, and sepcifically with Java, you can find all sorts of documentation
    > discussing threading issues and why using wait/notify is now the recommended
    > thread synchronization method, plus heaps of discussion *and examples* in
    > development forums about performance vs atomicity and mutex granularity. Yet
    > on VMS, all one hears is "I wouldn't do that if I were you" or "We know
    > something you don't know nah nah nanah nah" :-( If you are really that
    > concerned about what can go wrong with a global section application then why
    > don't you bring out a Technical Journal article with the "right" way to do
    > it? Perhaps a statistics Global Section that is being hammered by hundreds
    > of concurrent processes, discussing lighweight locking techniques vs the
    > DLM? Incorporate the new Infiniband API for cluster propagation and I'll
    > read it myself!
    >
    > Otherwise, let it be known, that sharing data between processes via a Global
    > Section (whether an installed PSECT or $crmpsc or VLM) is something that has
    > been done on VMS since about year dot. Maybe Larry Ellison should agree with
    > you and doesn't offer Cache Fusion on VMS? I see this as essential and basic
    > functionality that people should be able to receive support for and not the
    > usual "As seen at Gezelter labs" or "While I was speaking to Koffee and
    > Butrus Butrus the other day at my address to the G7".
    >
    > Regards Richard Maher
    >
    > "Bob Gezelter" wrote in message
    >
    > news:8a3dbb4d-bfc9-433b-ba9f-efa9b3ae84ec@q26g2000prq.googlegroups.com...
    >
    > > On Oct 8, 5:52 am, "Richard Maher"
    > > wrote:
    > > > Hi Adrian,

    >
    > > > (Not so much for your benefit as for aothers that may be reading here)

    >
    > > > Please do not listen to the incompetent filfth that have responded here!
    > > > Heaven forbid that VMS has to contend with the "Can't handle shared

    > memory
    > > > slur" on top of everything else :-(

    >
    > > > There is nothing wrong with "COMMON" areas and shared PSECTs! Tell the

    > usual
    > > > suspects to "you know what"!

    >
    > > > OOh! Global Sections are spooky; leave them to Unix! What about Cache
    > > > Fusion? What about an operating system that offers functionality? Global
    > > > Sections "a bridge too far"?

    >
    > > > You all make me sick!

    >
    > > > Regards Richard Maher

    >
    > > > "Ade" wrote in message

    >
    > > >news:rYlGk.35222$0D6.20078@newsfe01.ams2...

    >
    > > > > Hi,

    >
    > > > > Does anyone have a quick example of how to create a shareable image

    > using
    > > > > Pascal on IA64 (or please correct the code below). It is intended that
    > > > this
    > > > > image, when installed with /open/header/share/write, *will be used

    > simply
    > > > as
    > > > > a data repository for other applications which are linked together

    > with
    > > > it.
    > > > > All the examples I have seen in the documentation refer to shared

    > memory
    > > > > between linked object files rather than against a shareable image. Any
    > > > help
    > > > > you can give me would be greatly appreciated.

    >
    > > > > Regards,

    >
    > > > > Adrian Birkett

    >
    > > > > My example:

    >
    > > > > $ edit common.pas
    > > > > { potential common storage module }
    > > > > [environment ('common')]
    > > > > module common;
    > > > > type
    > > > > * * common_r = record
    > > > > * * * * my_int : integer;
    > > > > * * * * my_str : varying [10] of char;
    > > > > * * end;
    > > > > end.

    >
    > > > > $ pascal common.pas
    > > > > $ link common/share
    > > > > $ install add/open/head/share/write disk1:[dir]common.exe
    > > > > $ define common disk1:[dir]common.exe

    >
    > > > > $ edit prog1.pas
    > > > > {simple data writer program}
    > > > > [inherit ('disk1:[dir]common')]

    >
    > > > > program prog1(input output);
    > > > > var * *common:[common]common_r;
    > > > > begin
    > > > > * * common.my_int := 1000;
    > > > > * * common.my_str := 'Hello';
    > > > > end.

    >
    > > > > $ pascal/debug/nooptim prog1
    > > > > $ link prog1, sys$input/opt
    > > > > disk1:[dir]common.exe/share
    > > > > $ run prog1 !step through to end

    >
    > > > > [in a different process]

    >
    > > > > $ edit prog2.pas
    > > > > {simple data reader}
    > > > > [inherit ('disk1:[dir]common')]

    >
    > > > > program prog2(input output);
    > > > > var * *common:[common]common_r;
    > > > > begin
    > > > > * * writeln('int = ', common.my_int);
    > > > > * * writeln('str = ', common.my_str);
    > > > > end.

    >
    > > > > $ pascal/debug/nooptim prog2
    > > > > $ link prog2, sys$input/opt
    > > > > disk1:[dir]common.exe/share
    > > > > $ run prog2 * * * *!noting that prog1 is still running in your other
    > > > process
    > > > > int = * * * * 0
    > > > > str =

    >
    > > Richard,

    >
    > > I normally do not respond to comments of this sort, but a
    > > clarification is in order. As I can read it, none of the posts in this
    > > thread said "OpenVMS cannot do it". What was said was "In almost all
    > > cases, this is a dangerous practice".

    >
    > > I have NEVER claimed that OpenVMS cannot handle shareable storage,
    > > merely that in my extensive, 30+ year experience, I have seen far move
    > > (actually, overwhelmingly more) incorrect implementations of shared
    > > memory management than I have seen correctly done ones.
    > > Synchronization errors (e.g., race conditions) are devilish difficult
    > > to identify and eliminate, and virtually impossible to reproduce on
    > > demand. Avoiding deadlocks and synchronization starvation in complex
    > > systems is even more difficult.

    >
    > > Even something as simple as setting switch variable can be fraught
    > > with hazard. Many programmers who first learned to program using COBOL
    > > (and indeed, those working in COBOL) use strings to store switch
    > > values. In one of my AST talks (admittedly multithread -- AST and
    > > regular; not multiprocessor, which is worse) I reminded attendees that
    > > the MOVC3 and MOVC5 instructions were interruptable, thus could be
    > > interrupted by a number of events, including AST delivery. The
    > > "simple" act of setting changing a switch string from "YES" to "NO "
    > > could give rise to intermediate values of "YO ", "YE ", "NES", "NOS",
    > > etc.). Nobody in the audience had considered that possibility
    > > (admittedly several members of Engineering who heard about my example
    > > found it amusing). The same thing can happen with inadvertantly mis-
    > > aligned data. At one conference, someone overheard my discussion of
    > > that hazard and realized that that was the likely reason why his large
    > > scale simulation system sporadically produced invalid floating point
    > > values.

    >
    > > These problems are exacerbated when the underlying architecture or
    > > processor is changed, and the timing relationships alter.I have even
    > > seen situations where a change in the IO configuration caused timing
    > > issues.

    >
    > > My overall recommendation is to proceed with EXTREME care. A LINK, or
    > > a simple test case is far different than multiple processes doing a
    > > lot of work at high speed. It is all too easy to jump into shared
    > > memory as a way to avoid complexity and become mired in a quagmire.
    > > Since I have not seen Adrian's code base, I do not know if this is a
    > > highly dynamic global area, or a set of read-only parameters. Even a
    > > set of shared performance counters can become complex.

    >
    > > If the application is something along the lines of a large scale cache
    > > (e.g., RMS global buffers, a DBMS, a very high performance system)
    > > than I would consider the option of global storage, after:
    > > - the fact of the global storage was hidden behind an *API (or at
    > > least a set of macros)
    > > - a first implementation of the API was done using a resource monitor
    > > model (a separate process that implemented the data store)
    > > - the performance issue was severe enough to justify the extensive
    > > developer time and review to make sure that the implementation was
    > > valid and reliable.

    >
    > > As noted, I had a most entertaining converesation more than a decade
    > > ago on the implementation of a stock trading message switch where the
    > > client took exception to not using shared commons (I used DECnet
    > > logical links, a client subroutine shareable library, and a central
    > > datalink and server process; in effect a non-privileged device driver/
    > > ACP model) to implement data link management. They even wanted me to
    > > guarantee that if the performance was not adequate, I would
    > > reimplement things at no charge.

    >
    > > I did the implementation on an Alphastation 3000, and the bottleneck
    > > was somewhere around 10K transactions/minute. I was limited by the
    > > trace code (using DECterm) and the link to the trading switch. I
    > > probably could have gone quite a bit further with a little work. The
    > > beta went into production without any problems.

    >
    > > I had a similar experience several years earlier with an application
    > > that was supposed to support multiple terminals. It was quite a bit
    > > more cost effective to install the single user image as a shareable
    > > image than it was to spend man years to work multithreading the
    > > application. It was also far more resilient.

    >
    > > Rule 1: Architect allowing the complex solution, but use a less
    > > complex solution if at all possible. Context switches between
    > > processes may be costly, but system crashes in the middle of the day,
    > > are far costlier.

    >
    > > Thus, my comment that if one is in the applications business, one
    > > should "Tread with care"

    >
    > > - Bob Gezelter,http://www.rlgsc.com


    Richard,

    With all due respect, it would appear that my previous posting from
    October 8 has been misunderstood.

    My recommendation of EXTREME CAUTION with regards to shared memory is
    not a OpenVMS-specific recommendation. It is a global recommendation
    across all operating systems, real-time monitors, and executives [I
    think that about covers all of the possibilities, if I have omitted
    some class of systems, I assure everyone that the omission is
    unintentional].

    For extremely high performance and heavily used situations, where the
    engineering effort is appropriate to the task, I have NEVER said that
    shared memory techniques (e.g. caches, shared counters) are ipso facto
    erroneous, just that they are appropriate in certain situations and
    not in other situations. In OpenVMS, RMS global buffers, and the
    Oracle caches are certainly appropriate uses, with the engineering
    effort behind them to hopefully prevent problems. A set of counters
    being updated at high rates (multi-thousands/second), if properly
    implemented, is also an appropriate usage.

    Regrettably, what I have encountered on more than a few occasions is
    less rigorously done implementations, done because the proper locking
    was "too complex" or "it seems to work". When these approaches fail,
    the results are, to put it mildly, spectacular. Unless one quickly
    realizes what has happened, debugging these is often very time
    consuming. Frequently, they are the cause of chronic, unexplained
    failures of applications. As is said, "Been there, done that, have the
    shirt" [actually, probably several dressers full of them].

    As stated in my October 8 post, I more often encounter a belief that a
    non-shared memory approach is not sufficiently efficient. In my
    experience, this is virtually never backed by hard data, merely a
    "from the gut" feeling. As I mentioned previously, I have demonstrated
    that this belief is misplaced. As a guard against understatement, I
    generally obscure the precise implementation behind an internal API/
    library.

    The discussion of wait/notify, atomicity, and threading is an involved
    one, and has many latent issues. I do not have the citation handy, but
    about a decade ago, a major *NIX player (my recollection is that it
    may have been Sun's CTO), was quoted as observing that "perhaps events
    are a better processing model than threads". At that time I
    wholeheartedly agreed and I remain a believer in the structural
    advantages of avoiding applications level parallelism unless it is
    actually needed. I see far more poor implementations than good ones.
    This is even true on major fielded products in the *IX and Wintel
    spaces. [Tangentially, keep an eye out for packages that seem to
    consume all available CPU cycles, even when idle. Such designs are
    inherently not optimized for efficiency, nor are they likely to be
    frugal consumers of CPU cycles, and hence power and cooling. Such
    designs will have to be redone to play correctly in an increasingly
    "Green" environment.]

    As for the commercial aspect you alluded to in the response to my
    post, I do not accept the assertion that I am spreading FUD. I would
    rather that these difficult to resolve bugs never put in an
    appearance. Fixing them can be very costly. Indeed, getting the
    designs correct reduces development time and expense. The "cheaper"
    approach is far more expensive when problems inevitably occur.

    While I have, and do, consult on both troubleshooting and development,
    it makes me far happier to invoice a client for a successful smaller
    project. As mentioned previously, one project was projected to be six
    months and several man-years over schedule. It was multi-threaded for
    the sake of "efficiency". This was proven by the fact that the system
    was at 100% saturation. With nothing happening. I identified and
    corrected the reason for CPU saturation, a infinite dispatching loop
    in the scheduler. With that corrected, usage fell to about 1%. I then
    installed the application image using INSTALL, and we were able to run
    as many stations as we wanted, each using a copy of the application.
    This took days, not months. The code changes were tens of lines, not a
    total re-write. Obviously, by solving the client's problem, I did not
    maximize my income.

    In summary, I am not and never have been against the appropriate use
    of globally shareable memory. The key word in the preceding sentence
    is "appropriate".

    - Bob Gezelter, http://www.rlgsc.com

+ Reply to Thread