I've tested in more than one SO, and the problem is the same. Try to increase the number of threads, in order to increase concurrency and you will get the same result.

Here is one copy running 1000 concurrent threads:

C:\test>junk4 -NTHREADS=1000
STOP: Tue May 19 16:26:26 2009
1000000 1242746771.5932.out
[download]

And this is 20 concurrent copies each running 100 concurrent threads each:

C:\test>for /l %i in ( 1,1,20 ) do @start /b junk4 -NTHREADS=100
STOP: Tue May 19 16:07:35 2009
 100000 1242745650.6976.out
STOP: Tue May 19 16:07:35 2009
 100000 1242745651.0876.out
STOP: Tue May 19 16:07:36 2009
 100000 1242745651.15.out
STOP: Tue May 19 16:07:37 2009
 100000 1242745651.7896.out
STOP: Tue May 19 16:07:48 2009
STOP: Tue May 19 16:07:48 2009
STOP: Tue May 19 16:07:49 2009
STOP: Tue May 19 16:07:50 2009
STOP: Tue May 19 16:07:51 2009
STOP: Tue May 19 16:07:51 2009
STOP: Tue May 19 16:07:51 2009
STOP: Tue May 19 16:07:51 2009
STOP: Tue May 19 16:07:52 2009
STOP: Tue May 19 16:07:52 2009
STOP: Tue May 19 16:07:52 2009
STOP: Tue May 19 16:07:52 2009
 100000 1242745654.972.out
 100000 1242745654.8784.out
 100000 1242745656.0952.out
STOP: Tue May 19 16:07:52 2009
STOP: Tue May 19 16:07:52 2009
STOP: Tue May 19 16:07:52 2009
STOP: Tue May 19 16:07:52 2009
 100000 1242745656.142.out
 100000 1242745656.1576.out
 100000 1242745657.1092.out
 100000 1242745657.1716.out
 100000 1242745657.9048.out
 100000 1242745657.5304.out
 100000 1242745657.3432.out
 100000 1242745657.2652.out
 100000 1242745656.5476.out
 100000 1242745655.596.out
 100000 1242745655.8768.out
 100000 1242745654.7536.out
 100000 1242745654.3012.out
[download]

Nary a whiff of a problem. Still unconvinced it works fine here?

Is that other OS (I assume that's what you meant by SO?), based on the same kernel? Or compiled against the same CRT? Or both?

I've tested in this PCs:

PC 1

-bash-3.00$ uname -a
SunOS reia 5.10 Generic_137137-09 sun4v sparc SUNW,Sun-Blade-T6320
-bash-3.00$  perl -Mthreads -e 'print $threads::VERSION . "\n"'; perl 
+-Mthreads::shared -e 'print $threads::shared::VERSION . "\n"' ; perl 
+-v
1.71
1.27

This is perl, v5.8.8 built for sun4-solaris-thread-multi
[download]

PC 2

-bash-3.00$ uname -a
SunOS deimos 5.10 Generic_138889-03 i86pc i386 i86pc
-bash-3.00$ perl -Mthreads -e 'print $threads::VERSION . "\n"'; perl -
+Mthreads::shared -e 'print $threads::shared::VERSION . "\n"' ; perl -
+v
1.72
1.28

This is perl, v5.8.8 built for i86pc-solaris-thread-multi
[download]

PC 3

$ uname -a
Linux communicator 2.6.27-11-generic #1 SMP Wed Apr 1 20:57:48 UTC 200
+9 i686 GNU/Linux
$ perl -Mthreads -e 'print $threads::VERSION . "\n"'; perl -Mthreads::
+shared -e 'print $threads::shared::VERSION . "\n"' ; perl -v
1.67
1.14

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi
[download]

What do you mean by CRT?

What do you mean by CRT?

CRT == C RunTime libraries.

Presumably all the versions of perl you tested were built using GCC and its runtime libraries? If those libraries have a bug they could be affecting all the versions you've tried.

Another, and possibly more likely candidate is that the PERLIO implementation for unix/POSIX platforms has a bug that doesn't manifest itself in the MSWIN branches of the source tree.

Two things that you could try--if you have the inclination to try and track this down:

1. Re-build your local perl setting USE_PERLIO = undef or whatever the equivalent configuration parameter is for your system(s).
2. See if you can get someone who runs perl under cygwin (and/or Strawberry Perl) to see if they can reproduce the problems you are having.

Beyond that, report the problem to the threads maintainer and see what if any reaction you get.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."