[MPlayer-dev-eng] MplayerXP vs Mplayer. Hall of truth.
Steven M. Schultz
sms at 2BSD.COM
Sun Mar 17 18:29:20 CET 2002
> From: Daniel Egger <degger at fhm.edu>
> Threads are useful if you can find blocking tasks which are
> parallelisable and thus prevent maximum cpu utilisation. Threads have
> several drawbacks, one of them are locking issues another one would
> be overhead for the thread management, another one would be harder
> debugability, another one would be the against-nature of threads versus
> processes on Unixsystems.
To that list I would add portability issues. Unless done carefully
threading a program causes a program to become less portable.
One of the key problems is that of the default 'mutex attribute'.
Other systems (Solaris for example, *BSD* systems for another) use
'error checking' mutexes. This difference can make a program
almost completely unportable unless care is taken. One method I
have seen used to enhance portability is to this logic when
pthread_mutexattr_t *p_attr = &mu_attr;
pthread_mutexattr_settype( &mu_attr, PTHREAD_MUTEX_ERRORCHECK );
pthread_mutexattr_t *p_attr = NULL;
pthread_mutex_init( &frame_buffer_lock, p_attr );
> Please use threads only iff there's some real value in that.
Yes indeed. The paradigm of multiple processes communicating thru
a shared memory segment provides many of the advantages of threads
and is often easier to debug.
sms at 2bsd.com
More information about the MPlayer-dev-eng