native win32 threads or pthreads-win32?

[a***@arrozcru.no-ip.org]

Hello,

While making the win32 builds, I came across the decision of using
either native win32 threads (w32thread.c), or pthreads, with the
pthreads-win32 library.

The builds at http://ffdshow.faireal.net/mirror/ffmpeg/ include
pthreads-win32, but I didn't get any answer from celtic druid about
his decision.

Are there any issues that would make me prefer one over the other,
such as stability or performance?

Also, there are two issues I would like to remember:
1. Some gccs not returning error on -pthread unrecognized option.
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/35180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15303
Måns, did you take a deeper look into this? I couldn't find any simple
solution, and I don't really know what other projects did about this.
Anything besides "don't use gcc versions x to y"?

2. When mingw32 is selected (or os2, or beos), their native threads are
automatically used. If pthreads are also chosen, they will conflict:
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/26842
Would it be ok to only include HAVE_W32THREADS if test "$pthreads"
!= "yes"?
(configure, around line 2012).
I haven't tested this yet. I'll submit a patch when I get this tested.
Could this also be a problem with os2 and beos when pthreads are specified,
or do they not have any libpthreads?

Thanks,
Ramiro Polla

[a***@arrozcru.no-ip.org]

Hmmm... Not one reply... Not even about the "unrecognized option"
problem in gcc. Should I make a new thread about this issue without so
many 'win32's written in the subject?

Post by a***@arrozcru.no-ip.org
Hello,
While making the win32 builds, I came across the decision of using
either native win32 threads (w32thread.c), or pthreads, with the
pthreads-win32 library.
The builds at http://ffdshow.faireal.net/mirror/ffmpeg/ include
pthreads-win32, but I didn't get any answer from celtic druid about his
decision.
Are there any issues that would make me prefer one over the other, such
as stability or performance?
1. Some gccs not returning error on -pthread unrecognized option.
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/35180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15303
Måns, did you take a deeper look into this? I couldn't find any simple
solution, and I don't really know what other projects did about this.
Anything besides "don't use gcc versions x to y"?
2. When mingw32 is selected (or os2, or beos), their native threads are
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/26842
Would it be ok to only include HAVE_W32THREADS if test "$pthreads"
!= "yes"?
(configure, around line 2012).
I haven't tested this yet. I'll submit a patch when I get this tested.
Could this also be a problem with os2 and beos when pthreads are specified,
or do they not have any libpthreads?
Thanks,
Ramiro Polla

[Víctor Paesa]

Hi,

Post by a***@arrozcru.no-ip.org
Hmmm... Not one reply... Not even about the "unrecognized option"
problem in gcc. Should I make a new thread about this issue without so
many 'win32's written in the subject?

Post by a***@arrozcru.no-ip.org
Hello,
While making the win32 builds, I came across the decision of using
either native win32 threads (w32thread.c), or pthreads, with the
pthreads-win32 library.
The builds at http://ffdshow.faireal.net/mirror/ffmpeg/ include
pthreads-win32, but I didn't get any answer from celtic druid about his
decision.
Are there any issues that would make me prefer one over the other, such
as stability or performance?
1. Some gccs not returning error on -pthread unrecognized option.
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/35180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15303
Måns, did you take a deeper look into this? I couldn't find any simple
solution, and I don't really know what other projects did about this.
Anything besides "don't use gcc versions x to y"?
2. When mingw32 is selected (or os2, or beos), their native threads are
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/26842
Would it be ok to only include HAVE_W32THREADS if test "$pthreads"
!= "yes"?
(configure, around line 2012).
I haven't tested this yet. I'll submit a patch when I get this tested.
Could this also be a problem with os2 and beos when pthreads are specified,
or do they not have any libpthreads?

The man gcc page says that the -pthread/-pthreads flags are machine
dependent options, needed for SPARC, PowerPC, IA-64.
I can only speak for Cygwin, but in this platform is produces a warning.

We could reduce warning verbosity by setting this flag only in the SPARC,
PowerPC, IA-64 specific sections of configure.

The man ld page says nothing about these flags, I believe the
"check_ldflags -pthreads" in configure could be removed.

I am speaking as of gcc 3.4.4 / ld 2.17.50, maybe older versions behave
differently.

Regards,
Víctor Paesa

[herve.flores]

Post by Víctor Paesa
Hi,

Post by a***@arrozcru.no-ip.org
Hmmm... Not one reply... Not even about the "unrecognized option"
problem in gcc. Should I make a new thread about this issue
without so
many 'win32's written in the subject?

Post by a***@arrozcru.no-ip.org
Hello,
While making the win32 builds, I came across the decision of using
either native win32 threads (w32thread.c), or pthreads, with the
pthreads-win32 library.
The builds at http://ffdshow.faireal.net/mirror/ffmpeg/ include
pthreads-win32, but I didn't get any answer from celtic druid about his
decision.
Are there any issues that would make me prefer one over the
other, such
as stability or performance?
1. Some gccs not returning error on -pthread unrecognized option.
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/35180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15303
Måns, did you take a deeper look into this? I couldn't find any simple
solution, and I don't really know what other projects did
about this.
Anything besides "don't use gcc versions x to y"?
2. When mingw32 is selected (or os2, or beos), their native
threads are
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/26842
Would it be ok to only include HAVE_W32THREADS if test
"$pthreads"
!= "yes"?
(configure, around line 2012).
I haven't tested this yet. I'll submit a patch when I get this tested.
Could this also be a problem with os2 and beos when pthreads are specified,
or do they not have any libpthreads?

The man gcc page says that the -pthread/-pthreads flags are machine
dependent options, needed for SPARC, PowerPC, IA-64.
I can only speak for Cygwin, but in this platform is produces a warning.
We could reduce warning verbosity by setting this flag only in the SPARC,
PowerPC, IA-64 specific sections of configure.
The man ld page says nothing about these flags, I believe the
"check_ldflags -pthreads" in configure could be removed.
I am speaking as of gcc 3.4.4 / ld 2.17.50, maybe older versions behave
differently.
Regards,
Víctor Paesa

just for information, -pthreads is broken too with Mac (since some
months)
there is 274 warnings during compile ("-pthread unrecognize option")
But for Darwin, pthreads are in the lib system, in theory, there is
no need to an supplementary option (it's supposed to be always linked)

$ nm /usr/lib/libSystem.dylib | grep pthread_create
900e69ce T __pthread_create
90024153 T _pthread_create
9006652f T _pthread_create_suspended_np

There is no option -pthread for Darwin, but during pthreads tests,
the option nevertheless passed (in hard in configure). As GCC passes
the test of - pthread (a warning is not regarded as a failure), the
flag passed then but there would not need any.
On the other hand, the warning break all abilities to use Darwin
pthreads (ffmpeg didnt use more than 1CPU on my 2CPU hardware since
some months=theses warnings)

bye


Hervé

[Dana Hudes]

Post by a***@arrozcru.no-ip.org
While making the win32 builds, I came across the decision of using
either native win32 threads (w32thread.c), or pthreads, with the
pthreads-win32 library.
The builds at http://ffdshow.faireal.net/mirror/ffmpeg/ include
pthreads-win32, but I didn't get any answer from celtic druid about his
decision.
Are there any issues that would make me prefer one over the other, such
as stability or performance

You will certainly get better performance with native win32 threading if
you are running natively on win32 rather than cygwin. Are you compiling
with gcc somehow or are you using Microsoft's compiler? I don't have a
current MS compiler so I can't build native win32 though I have a dual
core PIV running win XP. pthreads (POSIX threads) run in user space,
only. I wouldn't expect them to get scheduled on another cpu. You have
to understand the various types of threading and indeed what threading
IS. Threads are running in the context of the parent process -- that's
the point. Some OS, such as recent Linux kernel and Solaris (I think at
least Solaris 9, certainly 10 possibly 8 and I doubt 2.6) have kernel
and user level threads. In fact, a process can be treated as a
kernel-level thread. The question is whether the OS scheduler, the one
running the system-wide run queues, is aware that there's this thread
out there. Otherwise its all just the parent process activity.

You can get a good overview of threading from the Microsoft
documentation. Back when I taught operating systems, we found a classic
concurrency example implemened (and throughly documented) on some MS
website -- IIRC, it was the frog and fly problem. Most of my students,
the ones not sleeping in class or screwing off their homework, were able
to understand MS thread model from the code and documentation (combined
with the foundations on threading and on concurrency from my lectures
and the textbook (Silberschatz, highly recommended) ) and were then able
to implement the Barbershop problem at some level. Sine most folks
reading this are presumably more advanced than junior year undergraduate
CS students, you should be able to get a good idea of it from the MS
website in question as well. I don't have the url handy but I'll see
about digging it up....though this starts to wander off-topic of the list.

[Borat]

Dana Hudes wrote:

(Ramiro Polla:)

Post by Dana Hudes

Post by a***@arrozcru.no-ip.org
While making the win32 builds, I came across the decision of using
either native win32 threads (w32thread.c), or pthreads, with the
pthreads-win32 library.

You will certainly get better performance with native win32 threading if
you are running natively on win32 rather than cygwin.

Another advantage of using native threads is the independency of
the 'pthreadGC2.dll' shared object file.

--
regards,
B.