From: brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill)
Subject: Re: OS/2 vs NT features list, Revision 1.4
Date: 4 Sep 92 15:04:47 MDT
Organization: University of Utah CS Dept

In article <1992Sep4.202736.1565@Informatik.TU-Muenchen.DE> rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) writes:
>In article <1992Sep4.105353.25246@hellgate.utah.edu> brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill) writes:
>>In article <1992Sep4.071734.3972@actrix.gen.nz> conrad@actrix.gen.nz (Conrad Bullock) writes:
>>>In article <1992Sep2.170400.10092@hellgate.utah.edu> brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill) writes:
>>>
>>>> OS/2 vs NT features list, Revision 1.4
>>>
>>>> Features currently in Windows NT but not in OS/2 2.0
>>>
>>>> 	Generic wait on multiple events/semaphores of different types.
>>>> 		This is helps prevent deadlocks.  Consider the classic
>>>> 		deadlock example: Two processes, P1 and P2, both want
>>>> 		to access tape drives A and B.  P1 locks A and waits for
>>>> 		B, P2 locks B and waits for A. Deadlock.
>>>> 		With the generic wait facility you say wake me when
>>>> 		I have both A and B.  This mechanism prevents many
>>>> 		deadlock problems.
>>>
>>>I think you're being slightly mischievous here - added an extra
>>>qualification without making it clear. OS/2 2.0 has DosWaitMuxWaitSem
>>>which allows you to wait on multiple semaphores - it does have the
>>>restriction that you can't mix event and mutex semaphores, but I don't
>>>know that that's a big problem. certainly in your example, both processes
>
>I have just looked up the Control Program Reference of the OS/2 2.0
>toolkit and the Semaphore sections clearly states that a
>DosWaitMuxWaitSem can wait on a mix of event and mutex semaphores.

Ah! this is different from what anyone's said before, I'll look closer and
make the appropriate changes.
(Actually I'll be glad if it's true, people drive me nuts with zillions
of questions about this one. :-))

>
>>>> 	Automatic stack expansion.
>>>> 		OS/2 2.0 does not (in the general case) have dynamic stack
>>>> 		extension. Someone inside IBM (and others) sent me this story.
>>>> 		Thread 1's stack is statically sized according to the value
>>>> 		you set in the executable at compile time.  Worse, all pages
>>>> 		of this stack are committed as the process starts, so you
>>>> 		don't want to grossly oversize the stack.  All other threads
>>>> 		do have dynamic stack extension.  Doing this somehow made
>>>> 		compatibility with older API's easier.
>
>As one can read in the OS/2 technical compendium (Redbooks) volume 1,
>pages 17 and 18, OS/2 provides automatic stack expansion. It is left to
>each program to allocate the stack area in a suitable manner and
>register an exception handler for guard page exceptions. I.e. it is the
>job of the compiler and runtime support implementors to add this
>feature to their compiler and library/runtime code. It happens that IBM
>C Set/2 and Watcom C386 do not provide this feature as the default
>while, for example, emx+gcc does have this feature (and there is
>currently even no way without it!).

Sigh, I have the following from somebody inside IBM who should know.
They told me that thread 1 simply cannot stack expand beyond the limit
you set at compile time, and further that the pages are committed when
the program starts.  This is (supposedly) a part of the executables format
so I don't understand how it could be different with emx+gcc.

Are you saying that you know 100% for certain that this is wrong?
(I realize you do gcc compiler work, so perhaps you do know...)
All I know is that is not what IBM has told me, and that under
C Set/2 things don't work that way.

Will people at IBM please find out for sure and e-mail me?

Confused,

Brian
-- 
C. Brian Sturgill                       *** OS/2 2.0 is for YOU! ***
University of Utah                  Microsoft needs some competition, but
Center for Software Science        -I- want to be one of the many using NT.
brian@cs.utah.edu; CIS: 70363,1373           :-) :-) :-)
Newsgroups: comp.os.os2.advocacy