Re: pthread: thread switching bug?

Re: pthread: thread switching bug?

[Christopher Faylor]

Please check out the project web page for links to available information
and ports:  http://cygwin.com/ .

If you don't see what you need there, then the cygwin mailing list is
the best place to make observations or get questions answered.
Information on the mailing list is available at the project web page.

For your convenience, I've reset the Reply-To: address to point to the
cygwin mailing list.  I've also Cc'ed this reply there.

On Wed, Oct 17, 2001 at 12:36:14AM +0200, Nemeth Marton wrote:
>Hi!
>
>I have written a little program using threads. If I complie with gcc &
>run it under Linux, it works fine.
>
>But when I complied with cygwin's gcc (used versions bellow), and run it
>there was some run where not all the newline characters were on the
>right place, like this:
>
>I'm thread #0, i=0, shared_data=0I'm thread #1, i=0, shared_data=1
>
>I'm thread #0, i=1, shared_data=2
>I'm thread #1, i=1, shared_data=3
>I'm thread #1, i=2, shared_data=4
>I'm thread #0, i=2, shared_data=5
>I'm thread #0, i=3, shared_data=6
>I'm thread #1, i=3, shared_data=7
>I'm thread #0, i=4, shared_data=8
>I'm thread #1, i=4, shared_data=9
>I'm thread #0, i=5, shared_data=10
>I'm thread #1, i=5, shared_data=11
>I'm thread #0, i=6, shared_data=12
>I'm thread #1, i=6, shared_data=13
>I'm thread #0, i=7, shared_data=14
>I'm thread #1, i=7, shared_data=15
>I'm thread #0, i=8, shared_data=16
>I'm thread #1, i=8, shared_data=17
>I'm thread #0, i=9, shared_data=18
>I'm thread #1, i=9, shared_data=19
>I'm thread #0, i=10, shared_data=20
>I'm thread #1, i=10, shared_data=21
>
>-------------------------------------
>
>I used the fallowing versions:
>$ gcc --version
>2.95.3-5
>
>$ /lib/gcc-lib/i686-pc-cygwin/2.95.3-5/cc1.exe -version
>GNU C version 2.95.3-5 (cygwin special) (i686-pc-cygwin) compiled by GNU
>C version 2.95.3-5 (cygwin specia
>l).
>options passed:
>options enabled:  -fpeephole -ffunction-cse -fkeep-static-consts
> -freg-struct-return -fsched-interblock -fsched-spec -fsjlj-exceptions
> -fcommon -fgnu-linker -fgcc-struct -fargument-alias -fident -m80387
> -mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387
>-mschedule-prologue
> -mstack-arg-probe -mcpu=pentiumpro -march=pentium
>
>$ /lib/gcc-lib/i686-pc-cygwin/2.95.3-5/collect2.exe -version
>GNU ld 2.11.92
>Copyright 2001 Free Software Foundation, Inc.
>This program is free software; you may redistribute it under the terms
>of
>the GNU General Public License.  This program has absolutely no
>warranty.
>  Supported emulations:
>   i386pe
>
>$ ld -version
>GNU ld 2.11.92
>Copyright 2001 Free Software Foundation, Inc.
>This program is free software; you may redistribute it under the terms
>of
>the GNU General Public License.  This program has absolutely no
>warranty.
>  Supported emulations:
>   i386pe
>
>
>$ cygcheck
>
>Cygnus Win95/NT Configuration Diagnostics
>Current System Time: Tue Oct 16 22:04:32 2001
>
>Win95 Ver 4.0 build 67109975  B
>
>Path:   /usr/local/bin
>        /usr/bin
>        /bin
>        /cygdrive/c/WINDOWS
>        /cygdrive/c/WINDOWS/COMMAND
>        /cygdrive/d/PROGRA~1/MICROS~2/OFFICE
>        /cygdrive/c/WINDOWS
>        /cygdrive/c/WINDOWS/COMMAND
>        /cygdrive/c/PROGRA~1/BORLAND/CBUILDER/BIN
>
>SysDir: C:\WINDOWS\SYSTEM
>WinDir: C:\WINDOWS
>
>PWD = `/home/samba'
>USER = `samba'
>MAKE_MODE = `unix'
>HOME = `/home/samba'
>
>PROMPT = `$p$g'
>COMSPEC = `C:\WINDOWS\COMMAND.COM'
>!C: = `C:\prg\cygwin\bin'
>CMDLINE = `bash --login -i'
>HOSTNAME = `NEMETH'
>CONFIG = `win95'
>WINDIR = `C:\WINDOWS'
>WINBOOTDIR = `C:\WINDOWS'
>PS1 = `\[\033]0;\w\007
>\033[32m\]\u@\h \[\033[33m\w\033[0m\]
>$ '
>BLASTER = `A220 I5 D1 T4'
>MACHTYPE = `i686-pc-cygwin'
>OLDPWD = `/usr/bin'
>TEMP = `/cygdrive/c/tmp'
>TMP = `/cygdrive/c/tmp'
>SHLVL = `1'
>WXWIN = `D:\PROGRA~1\WX2'
>SHELL = `/bin/bash'
>HOSTTYPE = `i686'
>OSTYPE = `cygwin'
>TERM = `cygwin'
>_ = `/usr/bin/cygcheck.exe'
>
>HKEY_CURRENT_USER\Software\Cygnus Solutions
>HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
>HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
>  (default) = `/cygdrive'
>  cygdrive flags = 0x00000022
>HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
>  (default) = `C:/prg/cygwin'
>  flags = 0x0000000a
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
>  (default) = `C:/prg/cygwin/bin'
>  flags = 0x0000000a
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
>  (default) = `C:/prg/cygwin/lib'
>  flags = 0x0000000a
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
>
>a:  fd           N/A    N/A                    
>c:  hd  FAT     2047Mb  92% CP    UN           SYS_WIN95
>d:  hd  FAT     2013Mb  92% CP    UN           
>e:  cd           N/A    N/A                    
>
>C:\prg\cygwin\bin  /usr/bin  system  binmode
>C:\prg\cygwin\lib  /usr/lib  system  binmode
>C:\prg\cygwin  /        system  binmode
>c:    /cygdrive/c  user    binmode,noumount
>d:    /cygdrive/d  user    binmode,noumount
>
>Found: C:\prg\cygwin\bin\bash.exe
>Found: C:\prg\cygwin\bin\cat.exe
>Found: C:\prg\cygwin\bin\cpp.exe
>Found: C:\prg\cygwin\bin\find.exe
>Found: c:\WINDOWS\COMMAND\find.exe
>Warning: C:\prg\cygwin\bin\find.exe hides c:\WINDOWS\COMMAND\find.exe
>Found: C:\prg\cygwin\bin\gcc.exe
>Found: C:\prg\cygwin\bin\gdb.exe
>Found: C:\prg\cygwin\bin\ld.exe
>Found: C:\prg\cygwin\bin\ls.exe
>Found: C:\prg\cygwin\bin\make.exe
>Found: C:\prg\cygwin\bin\sh.exe
>
>  701k 2001/09/13 C:\WINDOWS\SYSTEM\cygwin1.dll - os=4.0 img=1.0 sys=4.0
>                  "cygwin1.dll" v0.0 ts=2001/9/13 3:54
>    Cygwin DLL version info:
>        dll major: 1003
>        dll minor: 3
>        dll epoch: 19
>        dll bad signal mask: 19005
>        dll old termios: 5
>        dll malloc env: 28
>        api major: 0
>        api minor: 46
>        shared data: 3
>        dll identifier: cygwin1
>        mount registry: 2
>        cygnus registry name: Cygnus Solutions
>        cygwin registry name: Cygwin
>        program options name: Program Options
>        cygwin mount registry name: mounts v2
>        cygdrive flags: cygdrive flags
>        cygdrive prefix: cygdrive prefix
>        cygdrive default prefix: 
>        build date: Wed Sep 12 23:54:31 EDT 2001
>        shared id: cygwin1S3
>
>   56k 2000/12/03 C:\prg\cygwin\bin\cygbz21.0.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygbz21.0.dll" v0.0 ts=2000/11/20 23:53
>   81k 2000/12/05 C:\prg\cygwin\bin\cygitcl30.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygitcl30.dll" v0.0 ts=2000/11/26 1:43
>   35k 2000/12/05 C:\prg\cygwin\bin\cygitk30.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygitk30.dll" v0.0 ts=2000/11/26 1:43
>  390k 2000/12/05 C:\prg\cygwin\bin\cygtcl80.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygtcl80.dll" v0.0 ts=2000/11/26 1:39
>    5k 2000/12/05 C:\prg\cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0
>sys=4.0
>   10k 2000/12/05 C:\prg\cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygtclreg80.dll" v0.0 ts=2000/11/26 1:39
>  623k 2000/12/05 C:\prg\cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
>                  "cygtk80.dll" v0.0 ts=2000/11/26 1:43
>   45k 2001/04/25 C:\prg\cygwin\bin\cygform5.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygform5.dll" v0.0 ts=2001/4/25 5:28
>   26k 2001/04/25 C:\prg\cygwin\bin\cygmenu5.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygmenu5.dll" v0.0 ts=2001/4/25 5:27
>  156k 2001/04/25 C:\prg\cygwin\bin\cygncurses++5.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygncurses++5.dll" v0.0 ts=2001/4/25 5:29
>  226k 2001/04/25 C:\prg\cygwin\bin\cygncurses5.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygncurses5.dll" v0.0 ts=2001/4/25 5:17
>   15k 2001/04/25 C:\prg\cygwin\bin\cygpanel5.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygpanel5.dll" v0.0 ts=2001/4/25 5:27
>   34k 2001/09/30 C:\prg\cygwin\bin\cygform6.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygform6.dll" v0.0 ts=2001/9/30 2:43
>   19k 2001/09/30 C:\prg\cygwin\bin\cygmenu6.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygmenu6.dll" v0.0 ts=2001/9/30 2:43
>  175k 2001/09/30 C:\prg\cygwin\bin\cygncurses++6.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygncurses++6.dll" v0.0 ts=2001/9/30 2:45
>  201k 2001/09/30 C:\prg\cygwin\bin\cygncurses6.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygncurses6.dll" v0.0 ts=2001/9/30 2:42
>   12k 2001/09/30 C:\prg\cygwin\bin\cygpanel6.dll - os=4.0 img=1.0
>sys=4.0
>                  "cygpanel6.dll" v0.0 ts=2001/9/30 2:43
>   49k 2001/02/03 C:\prg\cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
>                  "cygz.dll" v0.0 ts=2001/2/3 20:35
>Use -h to see help about each section

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: pthread: thread switching bug?

[Robert Collins]

On Wed, 2001-10-17 at 10:36, Christopher Faylor wrote:
> Please check out the project web page for links to available information
> and ports:  http://cygwin.com/ .
> 
> If you don't see what you need there, then the cygwin mailing list is
> the best place to make observations or get questions answered.
> Information on the mailing list is available at the project web page.
> 
> For your convenience, I've reset the Reply-To: address to point to the
> cygwin mailing list.  I've also Cc'ed this reply there.
> 
> On Wed, Oct 17, 2001 at 12:36:14AM +0200, Nemeth Marton wrote:
> >Hi!
> >
> >I have written a little program using threads. If I complie with gcc &
> >run it under Linux, it works fine.
> >
> >But when I complied with cygwin's gcc (used versions bellow), and run it
> >there was some run where not all the newline characters were on the
> >right place, like this:

This simply indicates that the printf is not atomic. The Opengroup spec
for printf does not indicate atomicity as a requirement. It's certainly
not a 'thread switching bug' - thread scheduling is handled via Win32.

It *might* be an issue in newlib, or in the cygwin console fd handler,
neither of which I've checked yet.

Can you see whether you can reproduce the behaviour when writing to a
file, not to stdout? (If you are not using fprintf now, start by trying
with fprintf (stdout,...)). Let me know via the list whether you can
make this happen with a standard file/console with fprintf and we'll
take it from there,

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: pthread: thread switching bug?

[Robert Collins]

On Thu, 2001-10-25 at 07:04, Nemeth Marton wrote:
t.
> > 
> > Can you see whether you can reproduce the behaviour when writing to a
> > file, not to stdout? (If you are not using fprintf now, start by trying
> > with fprintf (stdout,...)). Let me know via the list whether you can
> > make this happen with a standard file/console with fprintf and we'll
> > take it from there,
> > 
> > Rob
> 
> I've checked the fallowing:
> 
>                     | without redirection | with shell redirection to
> file
>                     |                     | ">testfile.txt"
> --------------------|---------------------|---------------------------------
> printf(...)         | bug exist           | bug does not exist
> --------------------|---------------------|---------------------------------
> fprintf(stdout, ...)| bug exist           | bug does not exist
> --------------------|---------------------|---------------------------------
> 
>         NMarci
> 
> P.S. It seems that I couldn't post messages to cygwin@cygwin.com, that's
> why I do a CC also.

If you are behind a blocked mail server, you need to be subscribed to
post messages. That is documented in the bounce message AFAIK.

Thanks for the testing, you've shown that there is non thread safe code,
probably in the fhandler_consoler in cygwin, or possibly in the MS
Windows console code. Right now we don't know which.

This will get fixed... eventually :}. If you'd like to help fix it,
we're always happy to help a new developer get started.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: pthread: thread switching bug?

[Christopher Faylor]

On Thu, Nov 01, 2001 at 10:43:52AM +1100, Robert Collins wrote:
>On Thu, 2001-10-25 at 07:04, Nemeth Marton wrote:
>t.
>> > 
>> > Can you see whether you can reproduce the behaviour when writing to a
>> > file, not to stdout? (If you are not using fprintf now, start by trying
>> > with fprintf (stdout,...)). Let me know via the list whether you can
>> > make this happen with a standard file/console with fprintf and we'll
>> > take it from there,
>> > 
>> > Rob
>> 
>> I've checked the fallowing:
>> 
>>                     | without redirection | with shell redirection to
>> file
>>                     |                     | ">testfile.txt"
>> --------------------|---------------------|---------------------------------
>> printf(...)         | bug exist           | bug does not exist
>> --------------------|---------------------|---------------------------------
>> fprintf(stdout, ...)| bug exist           | bug does not exist
>> --------------------|---------------------|---------------------------------
>> 
>>         NMarci
>> 
>> P.S. It seems that I couldn't post messages to cygwin@cygwin.com, that's
>> why I do a CC also.
>
>If you are behind a blocked mail server, you need to be subscribed to
>post messages. That is documented in the bounce message AFAIK.

Yes, in the usual strange syncronicity that amazes and confounds us all,
this week's cause for consternation is the inability to send email to
cygwin@cygwin.com.  There are a few people who are puzzled by the
bounce messages.  I think this mainly owes to the fact that they are
not actually reading the bounce messages.

>Thanks for the testing, you've shown that there is non thread safe code,
>probably in the fhandler_consoler in cygwin, or possibly in the MS
>Windows console code. Right now we don't know which.

I'm still not sure why this is a cygwin bug.  Is there some requirement
that writes to the console be atomic?  Your (Robert's) original email
indicated that the Opengroup spec didn't have this as a requirement.

I'm sure that output to files is different than output to consoles
but I"m not sure that is a bug.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: pthread: thread switching bug?

[Christopher Faylor]

On Sat, Nov 03, 2001 at 12:50:06AM +0100, Heribert Dahms wrote:
>Hi Rob,
>
>I'd expect write() to be atomic, if "small" enough, but not print() or
>fprintf()!
>
>I once more cite APUE
>(Richard W. Steven's Advanced Programming in the UNIX Environment),
>chapter 10.6 Reentrant Functions:
>"Most implementations of the standard I/O library
>use global data structures in a nonreentrant way"

That is not true of newlib, AFAIK.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: pthread: thread switching bug?

[Heribert Dahms]

Hi Rob,

I'd expect write() to be atomic, if "small" enough, but not print() or
fprintf()!

I once more cite APUE
(Richard W. Steven's Advanced Programming in the UNIX Environment),
chapter 10.6 Reentrant Functions:
"Most implementations of the standard I/O library
use global data structures in a nonreentrant way"
right under figure 10.3:
Reentrant functions that may be called from a signal handler.

Methinks this precaution applies also to MT!


Bye, Heribert (heribert_dahms@icon-scm.com)

> -----Original Message-----
> From:	Robert Collins [SMTP:robert.collins@itdomain.com.au]
> Sent:	Thursday, November 01, 2001 03:38
> To:	cygwin@cygwin.com
> Subject:	RE: pthread: thread switching bug?
> 
> > -----Original Message-----
> > From: Christopher Faylor [ mailto:cgf@redhat.com ]
> > >Thanks for the testing, you've shown that there is non 
> > thread safe code,
> > >probably in the fhandler_consoler in cygwin, or possibly in the MS
> > >Windows console code. Right now we don't know which.
> > 
> > I'm still not sure why this is a cygwin bug.  Is there some 
> > requirement
> > that writes to the console be atomic?  Your (Robert's) original email
> > indicated that the Opengroup spec didn't have this as a requirement.
> 
> It's non expected behaviour at the least. At worst it could be a symptom
> of something more serious that is faulty. I intend to analyse it at some
> point. 
> 
> The Opengroup spec for printf doesn't document any thead safety needs,
> but, one would expect fprintf to a file to be atomic regardless of the
> actual file... There are separate thread considerations elsewhere in
> that tome, but I don't have time to dig them up right now.
> 
> Rob
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: pthread: thread switching bug?

[Christopher Faylor]

On Thu, Nov 01, 2001 at 01:38:03PM +1100, Robert Collins wrote:
>> -----Original Message-----
>> From: Christopher Faylor [ mailto:cgf@redhat.com ]
>> >Thanks for the testing, you've shown that there is non 
>> thread safe code,
>> >probably in the fhandler_consoler in cygwin, or possibly in the MS
>> >Windows console code. Right now we don't know which.
>> 
>> I'm still not sure why this is a cygwin bug.  Is there some 
>> requirement
>> that writes to the console be atomic?  Your (Robert's) original email
>> indicated that the Opengroup spec didn't have this as a requirement.
>
>It's non expected behaviour at the least. At worst it could be a symptom
>of something more serious that is faulty. I intend to analyse it at some
>point. 
>
>The Opengroup spec for printf doesn't document any thead safety needs,
>but, one would expect fprintf to a file to be atomic regardless of the
>actual file... There are separate thread considerations elsewhere in
>that tome, but I don't have time to dig them up right now.

I wouldn't be surprised to find that the "thread safety" of file writes
is actually due to the fact that file writes are *much* faster than
writes to the console.  Since cygwin processes every character that goes
to the console it isn't surprising to me that threads will interleave
their output.  There is certainly no console locking going on.

It's possible that CYGWIN=tty would also have a different behavior.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: pthread: thread switching bug?

[Robert Collins]

> -----Original Message-----
> From: Christopher Faylor [ mailto:cgf@redhat.com ]
> >Thanks for the testing, you've shown that there is non 
> thread safe code,
> >probably in the fhandler_consoler in cygwin, or possibly in the MS
> >Windows console code. Right now we don't know which.
> 
> I'm still not sure why this is a cygwin bug.  Is there some 
> requirement
> that writes to the console be atomic?  Your (Robert's) original email
> indicated that the Opengroup spec didn't have this as a requirement.

It's non expected behaviour at the least. At worst it could be a symptom
of something more serious that is faulty. I intend to analyse it at some
point. 

The Opengroup spec for printf doesn't document any thead safety needs,
but, one would expect fprintf to a file to be atomic regardless of the
actual file... There are separate thread considerations elsewhere in
that tome, but I don't have time to dig them up right now.

Rob

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/