Re: [boost] Re: Threads docs updated in CVS

From: Greg Colvin (greg_at_[hidden])
Date: 2001-08-10 10:42:21

From: Greg Colvin <greg_at_[hidden]>
> From: Alexander Terekhov <terekhov_at_[hidden]>
> > 
> > > On Windows, the thread::ref design does not require any reference
> > > counting and does not require any heap allocation: the thread::ref
> > > can be a very small object containing little more than a HANDLE.
> > 
> > the price you pay for thread handle replication is terrible!
> > 
> > as an illustration, just run the following program and
> > watch its output, kernel memory usage, kernel handle counter..
> 
> I modified your to program print out just the value of i every
> 10,000 calls, and to call getchar() only after 100,000 calls to
> DuplicateHandle.  At that point it had used up about 780K of kernel
> memory, or about 8 bytes per handle.  I let it keep running, and it
> got to over 700,000 calls before it ran out of handles.  So I don't
> see what the problem is, unless 5 million handles isn't enough.

Oops.  I meant to say, unless 5 megabytes is too much.

> > #include <windows.h>
> > #include <stdio.h>
> > 
> > int main()
> > {
> >   int i;
> >   for (i = 0; i < 10000; i++ ) {
> > 
> >     HANDLE cur = GetCurrentThread();
> >     HANDLE real;
> >     DuplicateHandle(GetCurrentProcess(), cur, GetCurrentProcess(), &real,
> >       0, FALSE, DUPLICATE_SAME_ACCESS);
> >     printf( "\n %p %p", cur,real );
> >     if ( i == 5000 )
> >       getchar();
> > 
> >   }
> >   getchar();
> >   return 0;
> > 
> > }
> > 
> > FFFFFFFE 0000002C
> > FFFFFFFE 00000028
> > FFFFFFFE 00000038
> > FFFFFFFE 0000003C
> > FFFFFFFE 00000040
> > FFFFFFFE 00000044
> > FFFFFFFE 00000048
> > FFFFFFFE 0000004C
> > FFFFFFFE 00000050
> > FFFFFFFE 00000054
> > FFFFFFFE 00000058
> > FFFFFFFE 00000068
> > FFFFFFFE 00000060
> > .
> > .
> > .
> > 
> > >
> > > So it isn't clear to me what your objection to the thread::ref
> > > design is, or to the current design for that matter.  All I can
> > > gather is that you hate the name "join" and prefer to risk race
> > > conditions with Events, which would be difficult to implement on
> > > pthreads, ...
> > 
> > you can implement win32 events as monitors using POSIX condition
> > variables..  e.g. pseudo-code (w/o PulseEvent/WaitForMultiple):
> 
> OK, they aren't hard to implement after all.  Like William, I can't
> imagine why one would want to.  But, as my dear old mother used to
> say: "Everybody to their own taste, said the lady as she kissed the
> cow."
> 
> 
> > init event:
> > 
> >   event->bManualReset = <manual_reset>  // const
> >   event->bIsSignalled = <initial_state>
> >   init event->mtxLock      // mutex
> >   init event->cndSignalled // condition variable
> > 
> > end init event
> > 
> > wait for event:
> > 
> >   lock event->mtxLock
> > 
> >   while not event->bIsSignalled
> >     cond_wait event->cndSignalled,event->mtxLock
> > 
> >   if not event->bManualReset // Auto-reset
> >     event->bIsSignalled = false
> > 
> >   unlock event->mtxLock
> > 
> > end wait for event
> > 
> > set event:
> > 
> >   lock event->mtxLock
> > 
> >   event->bIsSignalled = true
> > 
> >   unlock event->mtxLock
> > 
> >   if event->bManualReset
> >     broadcast event->cndSignalled
> >   else
> >     signal event->cndSignalled
> > 
> > end set event
> > 
> > reset event:
> > 
> >   lock event->mtxLock
> >   event->bSignalled = false
> >   unlock event->mtxLock
> > 
> > end reset event
> 
> 
> 
> 
> Info: http://www.boost.org  Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
>