namespace tool {

class thread_pool
{
private:
    array<HANDLE>         thread_handles;
    array<task*>          tasks;
    mutex                 guard;
    event                 got_something;
    volatile long         terminate;
    volatile long         active;
    
public:
    thread_pool(int n_pool_size = 5):
        terminate(0),active(0)

    void add_task(task *t)

    void start()
    void stop()
    {
       locked::set(terminate, 1);
       while(active > 0)
       {
         got_something.signal();
         yield();
       }
    }

protected:
    task* next_task();

    static DWORD WINAPI thread(LPVOID pParam)
    {
        thread_pool* pthis = static_cast<thread_pool*>(pParam);
        while(!pthis->terminate)
        {
            task *t = pthis->next_task();
            if(t)
            {
               t->exec();
               delete t;
            }
        }
        locked::dec(pthis->active);
        return 0;
    }
};

}

Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Included in Windows 95 and later.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.

long l;
locked::dec(l);

Забудь про volatile, когда ты используешь multithreading.

ME>long l;
ME>locked::dec(l);
ME>

struct locked
{
  static long dec(volatile long& v)
  {
    return InterlockedDecrement(&v);
  }
}

PVOID InterlockedCompareExchangePointer (
  PVOID volatile *Destination,  // destination address
  PVOID Exchange,               // exchange value
  PVOID Comperand               // value to compare
);

eao197 wrote:

> ... Поэтому еще раз проясню свою позицию: я хочу увидеть реальные примеры (из реальных, а не тестовых примеров), когда использовались примитивы синхронизации, но приложение все равно работало не правильно до тех пор, пока не было использовано volatile. При этом меня не интересуют ни обработчики аппаратных прерываний, ни работа с железом через отображаемые в память порты ввода/вывода.
>
> Прошу не приводить примеров, когда компилятору специальными ключами явно указывали, что ни одна функция не имеет побочных эффектов. Применение такого ключа в многопоточной программе, ИМХО, является проявлением излишнего оптимизма программиста. Кроме того, такой пример я уже видел. Может есть что-то еще?

Попытка использовать голые (не volatile) флаги вызывала очень странный behavior.
Вообще когда multithreading нечто начинает вести себя странно — ищи где ты забыл поставить volatile.

http://msdn.microsoft.com/library/en-us/vccore/html/_core_.2f.oa.2c_2f.ow.asp

Rules for Using /Oa and /Ow

If you use /Oa or /Ow, you must follow these rules. The following rules apply for any variable not declared as volatile:

No pointer can reference a variable that is used directly (a variable is referenced if it is on either side of an assignment or if a function uses it in an argument).

No variable can be used directly if a pointer to the variable is being used.

No variable can be used directly if its address is taken within a function.

No pointer can be used to access a memory location if another pointer modifies the same memory location.

Failing to follow these rules can cause corrupted data. If variables seem to take on random values, compile the program with Disable (/Od). If the problem goes away, try compiling with optimization but without /Oa or /Ow.

The following code can cause an aliasing problem:

i = -100;
while( i < 0 )
{
     i += x + y;
     *p = i;
}

Without /Oa or /Ow, the compiler assumes that the assignment to *p can modify x or y, so it does not assume that x + y is constant for each iteration. If you specify /Oa or /Ow, the compiler assumes that modifying *p does not affect x or y and the calculation of x + y can be removed from the loop.

> ME>long l;
> ME>locked::dec(l);
> ME>

> struct locked
> {
>   static long dec(volatile long& v)
>   {
>     return InterlockedDecrement(&v);
>   }
> }
>

   static long dec(long& v)
   {
     return InterlockedDecrement(&v);
   }

> PVOID InterlockedCompareExchangePointer (
>   PVOID volatile *Destination,  // destination address
>   PVOID Exchange,               // exchange value
>   PVOID Comperand               // value to compare
> );
>

long l;
long volatile* p1 = &l; // ok
long const volatile* p2 = &l; // ok
long* p3 = const_cast<long*>(p2); // cast required

Thank you for testing your code with Comeau C/C++!
Tell others about http://www.comeaucomputing.com/tryitout !

Your Comeau C/C++ test results are as follows:

Comeau C/C++ 4.3.3 (Aug  6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing.  All rights reserved.
MODE:strict errors C++

In strict mode, with -tused, Compile succeeded (but remember, the Comeau online compiler does not link).

1. Compiler documentation. Visual Studio в своей док-ции документирует свое implementation defined поведение volatile:
   

   ... the system always reads the current value of a volatile object at the point it is requested...

   So far so good. Также там говорится, что
   

   The volatile keyword is a type qualifier used to declare that an object can be modified in the program by something such as the operating system, the hardware, or a concurrently executing thread.

   Слов required/mandatory или даже recommended/advised мы здесь не встречаем.
   
2. Документация к API, в частности MSDN: DLLs, Processes, and Threads. Требования или даже рекоммендации использовать volatile shared variables мы здесь также не находим.
   
3. Док-ция к процессору, здесь — IA-32 Intel® Architecture Software Developer's Manual Volume 3: System Programming Guide. Здесь нам черным по белому пишут в §7.2.4:
   

   It is recommended that software written to run on Pentium 4, Intel Xeon, and P6 family processors assume the processor-ordering model or a weaker memory-ordering model. The Pentium 4, Intel Xeon, and P6 family processors do not implement a strong memory-ordering model, except when using the UC memory type. Despite the fact that Pentium 4, Intel Xeon, and P6 family processors support processor ordering, Intel does not guarantee that future processors will support this model. To make software portable to future processors, it is recommended that operating systems provide critical region and resource control constructs and API s (application program interfaces) based on I/O, locking, and/or serializing instructions be used to synchronize access to shared areas of memory in multiple-processor systems. Also, software should not depend on processor ordering in situations where the system hardware does not support this memory-ordering model.