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

From: Greg Colvin (greg_at_[hidden])
Date: 2001-08-10 00:34:30

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.

> #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