[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference clt::cma

Title:DECthreads Conference
Moderator:PTHRED::MARYSTEON
Created:Mon May 14 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1553
Total number of notes:9541

1498.0. "setenv PTHREAD_CONFIG meter=all" by ZYDECO::REDDY () Fri Feb 28 1997 11:24

    I have customer who did a setenv PTHREAD_CONFIG meter=all as suggested
    in the Guide to DECthreads and ran an application that uses posix
    threads.  This caused the application to hang.  The following program
    can be used to reproduce what he sees.  The only way to get out of it
    is to kill it. I read note 1489 and wonder if the problem is a deadlock 
    of some sort.
    
    Here is what I did:
    
    > cc dosystem.c -pthread -o dosystem
    > dosystem              # works
    > setenv PTHREAD_CONFIG meter=all
    > dosystem              # HANGS
    
    where dosystem.c contains:
    
    int main (int argc, char *argv[])
        {
        system ("ls");
        return 0;
    }
    
    
    Thanks,
    
    Sumithra
    
    
T.RTitleUserPersonal
Name
DateLines
1498.1DCEIDL::BUTENHOFDave Butenhof, DECthreadsFri Feb 28 1997 11:3728
First, you didn't even mention which version they're using, which is always a
bad way to start a problem report.

However, fork() will sometimes do that. Fork and threads really don't get
along at all well, in general. With enough whips and chairs, and a lot of
training, they can be made to put on a decent show for the tourists, but you
don't want to put your thread into a wild fork's mouth under normal
circumstances, if you can help it (and system() is just a subspecies of
fork()).

Metering requires resources hanging off each mutex/condition variable, and
when you fork sometimes we have no chance to acquire those resources before
it's too late. (This was easier before POSIX introduced static mutex
initialization, since we always had a chance to create the resources with
each synchronization object -- on the other hand, static initialization is a
cool idea, and even if it wasn't, we have to live with it.)

I suspect that you're running into a problem recently pointed out to us on
Digital UNIX 4.0 and later. In which case, it's a problem we can (and,
eventually, will) do something about. That doesn't mean there's not an
insolvable problem downstream from it, so I can't offer any guarantees. In a
future version, I'll have a chance to completely redesign metering in a way
that doesn't require resources hanging off each object -- which will make it
much more reliable and much less intrusive. But that's a big job. And someone
will still probably find another fork-tooth mark in a thread, somewhere,
sooner or later...

	/dave
1498.2<ZYDECO::REDDYFri Feb 28 1997 11:406
    
    Thank you.  I am sorry I forgot to add that I was using Digital UNIX
    4.0b.
    
    Sumithra