>From: Mark Heath <mjp...@silicontrip.org>
>
>I assume I'd need to use glib but it appears to be broken on my system.
>I also tried the gcc atomic operations but I've only got gcc 4.0.1.
>
>I've also sig_atomic_t but I've got no idea if it's reading and  
>incrementing as an atomic action.  The read and increment is such a  
>short duration I cannot get it to break even without locking.

        I think this talk of threaded applications says it's time for
        a reposting of my caution and plea for portability...


        Threaded programming is hard.  PORTABLE threaded programming is 
        very hard.

        Two things to keep in mind:  1) Check ALL return values and status
        indications (I've seen too many programs *assume* that 
pthred_mutex_unlock() 
        can not/will not fail) and 2) all the world is NOT linux (as much as
        some might think otherwise ;)).

        With those two cautions here's what I've posted several times over
        the years (and is what mjpegtools uses in mpeg2enc).  Happy reading :)

        With linux a mutex can, according to the manpages, be of type 'fast',
        'recursive' or 'error checking'.  The 'fast' type has no concept of
        thread "ownership" and any thread can unlock any mutex *even if it is
        not the thread that locked it*.   On the other hand the 'error checking'
        type does enforce mutex "ownership" and only the thread that locked
        a mutex may unlock it, attempting to unlock a mutex not owned by the
        thread returns an error (EPERM) - thus checking the status returned
        by pthread_mutex_lock() and pthread_mutex_unlock() is a good idea.

        FreeBSD, Solaris and BSD/OS all use 'error checking' mutexes (I did
        verify this with a simple test program).  MAC OS/X says unlocking a
        mutex not owned by the calling thread is undefined.  The default linux 
        mutex attribute is, for some unknown reason,  'fast'.

        As you can imagine a program that relies on 'fast' mutex behaviour
        will not function correctly on a system which uses 'error checking' 
        (i.e. ownership) mutexes (the reverse case might work - I haven't 
        tried it ;)).

        The workaround is to override the brain damaged default with:

#ifdef __linux__
        pthread_mutexattr_t mu_attr;
        pthread_mutexattr_t *p_attr = &mu_attr;

        pthread_mutexattr_init(&mu_attr);
        pthread_mutexattr_settype( &mu_attr, PTHREAD_MUTEX_ERRORCHECK );
#else
        pthread_mutexattr_t *p_attr = NULL;
#endif

        pthread_mutex_init( &frame_buffer_lock, p_attr);

                Cheers,
                Steven Schultz


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Reply via email to