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

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-09 13:50:40

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

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

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

regards,
alexander.

ps. here is my favorite MS link.. sorry, can not resist ;-)

http://support.microsoft.com/support/kb/articles/Q254/9/56.ASP

"INFO: Managing Thread Termination"
.
.
.
"Owned mutexes are considered abandoned but this can be detected.

 Other synchronization objects that the thread acquired are now
 left unreleased. For example, critical sections that were
 entered by the terminated thread are not released.

 If the target thread was executing certain kernel32 calls when
 it is terminated, the kernel32 state for the thread's process
 could be inconsistent.

 If the target thread is manipulating the global state of a
 shared DLL, the state of the DLL could be inconsistent,
 affecting other users of the DLL.

 The stack memory that is used by the thread is lost and not
 recovered until the process ends. A long-running process must
 not do this because eventually all its address space will be
 used. A few of these terminations a day over the course of a
 few months will cause this problem.

 Because of all these issues with state leakage and corruption,
 it is not a good idea to use the TerminateThread function."
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

;) ;)