Given (my) uncertainty about what happens when you mix MMF/threads/ties et al, I'd offer two alternative approaches:

  1. Have the per thread DB::DB() routines log the trace information to a common (queue) and start a separate thread that reads the queue and writes to the MMF.

    You still have the problem of arranging for different processes to write to different areas of that shared memory without collisions, along with synchronisation between processes.

    This way, you remove the in-process contention and the uncertainty of behaviour surrounding having multiple tied interfaces on separate ithreads attempting to juggle access to a single process global resource.

  2. Write the external Strace program as a (threaded) tcp server application and have the DB::DB() routines log directly to it via sockets.

    Each thread can create it's own connection to the external program which avoids adding complexity to the process you are trying to debug. You dodge all the problems associated with synchronisation and conflicts that arise by trying to share global resources between threads through tied interface. It would probably be a lot faster to boot.

    I'd use a queue in the server to coalesce the inputs from the clients into a coherent, ordered whole for saving or presentation.

I'd go for the latter approach, as I think that debug tools should impose as little complexity and overhead as possible upon the programs thet are debugging, and to my mind, opening and writing to a socket fits that bill quite well.

Trying to manage allocations of memory and synchronise access to them from multiple threads in multiple (unknown) processes; without creating deadlocks; and without your sync'ing and locking interfering with their own sync'ing and locking--given that you don't know what they might be doing, and indeed you are likely to be trying to help them debug it--just seems like too big a hill to climb.

Synchronisation of access to memory is the Achilles Heel of threads, and the best way of dealing with it is to avoid doing it whenever possible.

Beyond that, all I can do is wish you the very best of luck :)

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

In reply to Re^3: Win32::MMF + threads misbehavior by BrowserUk
in thread Win32::MMF + threads misbehavior by renodino

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.