[MPlayer-dev-eng] [PATCH] use pthreads for caching

[A Mennucc]

hi Rich

Rich Felker ha scritto:
> On Sat, Jan 27, 2007 at 02:04:16AM +0200, Uoti Urpala wrote:
> I agree. The beauty of MPlayer's cache code is that it works (or it's
> supposed to work; off_t larger than system wordsize puts a nasty kink
> in it..) without heavy thread-synchronization mechanisms, just simple
> processes with shared memory. I suspect linking to and initializing
> theads when they're not needed could active nasty locking mechanisms
> in the C library (malloc, etc.) possibly causing performance loss.

you are inexact in some important points in your reasoning here. Here
are some detailed clarifications:

----- point 1

> I suspect linking to and initializing
> theads when they're not needed 

when you run ./configure , there is already a snippet of code that tests
for pthreads :

vvvvvvvv
if test "$_pthreads" = yes ; then
  _res_comment="using $_ld_pthread"
  _def_pthreads='#define HAVE_PTHREADS 1'
  _def_threads='#define HAVE_THREADS 1'
else
  _res_comment="v4l, vo_gl, ao_alsa, ao_nas, ao_macosx, win32 loader
disabled"
  _def_pthreads='#undef HAVE_PTHREADS'
  _nas=no ; _tv_v4l1=no ; _macosx=no
  if not mingw32 ; then
    _win32=no
  fi
fi
echores "$_pthreads"
^^^^^^^^

so, in any running mplayer around, pthreads (when available) are already
 linked in

my caching code  is not adding a linking to pthreads to mplayer ; it is
just using it

---- point 2


look into
http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html

there is no command pthread_initialize()
to use threads, you just link the library in, and pthread_create() as needed

I tested with a simple two line program : if
 gcc -g -lpthread  test.c -o test
then 'info thread' in gdb reports one thread; if otherwise I do not put
-lpthread, 'gdb info thread'  does not report anything; so the mere fact
of linking to -lpthread is already initializing the NPTL system

if you gdb mplayer in linux, and 'info thread', you will see that
'mplayer' has one thread : so the pthreads are already initialized

> I suspect linking to and initializing
>> theads when they're not needed could active nasty locking mechanisms
>> in the C library (malloc, etc.) possibly causing performance loss.

this said, I do not know if pthread_create()  adds a nasty locking
mechanism in malloc

----- point 3

> heavy thread-synchronization mechanisms

there is no explicit thread-sync mechanism in my code

the caching code was designed to work w/o interprocess (or interthread)
synchronization mechanisms

so my patch does it that way

---------

regarding performance ... I will do a test later today;

but I would be really surprised if I see a performance penalty: I didn't
ever hear that NTPL threading has a performance loss versus having two
processes ...

I Googled around a bit and found that NPTL is indeed quite fast: e.g.
http://lwn.net/Articles/10710/
"(NGPT) implementation beat standard Linux threads by at least a factor
of two in these tests. The NPTL library, however, beat NGPT by about a
factor of four."

(no mention of forks , but at least you can see that NPTL was designed
to be quite fast)

Other stuff I found Googling says that NPTL beats the speed out
of other ways of doing concurrent computations.


a.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070127/4b66d2c9/attachment.pgp>