Re: [Mjpeg-users] writing multi threaded code
>From: Mark Heath > >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
Re: [Mjpeg-users] writing multi threaded code
> 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 ;)). A program the relies on undefined behaviour is broken. > The workaround is to override the brain damaged default with: It's a very sane default because the performance difference is astronomical > #ifdef __linux__ Far better is if (defined __linux__) && defined(DEBUG_MUTEXES) then you can build for debug or for performance as needed with a compile option. Even better still for many applications is not using pthreads in the first place. The fundamental models pthreads use are basically 'everything is shared, nothing is locked unless you remember to do so' and there is no object access v locking validation. In short it's got default behaviour of 'break invisibly' Java at least tried to get chunks of this right. -- 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
Re: [Mjpeg-users] writing multi threaded code
On Fri, 23 Sep 2011, Alan Cox wrote: > It's a very sane default because the performance difference is > astronomical I disagree. I do not see how having a thread which obtained a lock be the one which releases it causes any performance change. The same amount of unlocking is done. > > #ifdef __linux__ > Far better is > if (defined __linux__) && defined(DEBUG_MUTEXES) Better name would defined(NON_PORTABLE_MUTEXES) linux is the only system I've encountered which doesn't use the concept of thread ownership. And it was a big pain to port a program written to use the 'ownerless mutex' concept to systems which did use that concept. If the program is written to use the concept of thread ownershio (by turning on either DEBUG_MUTEXES or NON_PORTABLE_MUTEXES) then WHERE is the performance difference coming from? Turning that option off would make it easy to produce non portable threaded code. > then you can build for debug or for performance as needed with a compile > option. To me it is an egregious error for a thread which did not lock a mutex to unlock it -that's the way it's been for as long as I can remember. It has, in MY experience, always been a logic or design error for a thread to unlock a thread of which is it not the owner. > Even better still for many applications is not using pthreads in the OK with me.When I see the mjpegtools rewritten into whatever replaces pthreads I'll believe it ;) > first place. The fundamental models pthreads use are basically > 'everything is shared, nothing is locked unless you remember to do so' we have to live within the confines of the pthreads model unless someone volunteers to Wasn't trying to start a religious argument and it seems the reference to brain dead did push a hot button. Was simply pointing out that the default behaviour of a system that many use is not as portable as many would like to think. Java -> /dev/null 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
