И так в бою за титул чемпиона участвует два соперника
Win32Api(будем его так кликать):
    OS: Windows NT/95/98/me/2000/xp/vista/seven/ce(может не в той последовательности)

POSIX:
        OS: Unix/Linux(many)/Mac OS/QNX/(слышал про реализацию под Windows NT/95/98/me/2000/xp/vista/seven/ce правда уже не в комплекте).

Let's Begin(Давайте начнем)

1)Round "Mutual blocking(взаимо блокировка)":

    Win32Api представляет CRITICAL_SECTION и и Mutex.
    POSIX уверенно говорит о Mutex.

Win32Api:
    CRITICAL_SECTION            
        InitializeCriticalSection();
        EnterCriticalSection();
        TryEnterCritticalSection();
        LeaveCriticalSection();
        DeleteCriticalSection();

        Просты в использовании, выходят в режим ядра когда это действительно нужно. Из минусов можно сказать большой расход памяти(из-за структуры).
        Требуют обработку исключений(по крайней мере InitializeCriticalSection, 
                                        а если я использую С, __try __catch __finally вообщем расклад то не очень)
        -Распростроняются только на один процесс(хотя при желании можно и изменить, мы ведь знаем что в структуре есть handle семафора, но 
         наверное не стоит)
    Mutex:
        CreateMutex();
        OpenMutex();
        WaitForSingleObject();
        WaitForMultiObjects();
        ReleaseMutex();
        CloseHandle();
        
        Всегда используют ядро. Указатель на void наверное не самое лучшое решение, вдруг захочится узнать кто же все таки блокировал поток?
        Но есть и приимущества указатель на void стандартная функция уничножения, и ожидания. Большим приимушеством будет что поток может ожидать 
        несколько mutex's. Нет try lock  . Так же плюс что является мульти процессорным.

Posix:
    
    Mutex:    
        pthread_mutex_init();
        pthread_mutex_lock();
        pthread_mutex_trylock();
        pthread_mutex_unlock();
        pthread_mutex_destroy();

        Открытая структура, выходят в режим ядра когда это действительно нужно. Распростроняются только на один процесс. Нет возможности ожидания 
        больше одного mutexю
Кто победил? Трудновато сказать. Тут все завист от то кто что ожидает при использовании  "Mutual blocking(взаимо блокировка)". Лично мое мнение это Win32Api.

так что счет 1:0

2)Round "Semaphore":
Win32Api:
    CreateSemaphore();
    WaitForSingleObject();
    WaitForMultiObjects();
    ReleaseSemaphore();
    CloseHandle();
    
    В принципе все приимущества что и у Mutex. Не стоит думать как был создан(или же был открыт) семафор при уничтожении. Пожалуй не удобно при открытии 
    делать дубликацию HANDL.
Posix:
    sem_init();
    sem_wait();
    sem_post();
    sem_trywait();
    sem_getvalue();
    sem_destory();
    sem_open();
    sem_close();
    sem_unlink();
    Надо помнить как все же был создан(или был открыт) семафор при уничтожении. Приимучество можно получить счетчик, и есть try wait.

Думаю здесь честно победу можно отдать Win32Api.
Так что счет 2:0


3)Round "Atomic operation or Interlocked(Атомарные операции или Interlocked(мне не нравится перевод))"

Win32Api:
    InterlockedDecrement();
    InterlockedIncrement();
    InterlockedAdd();
    Ну и в таком духе.
    Приимуществ нет. Не достаток вызывают DLL, соответственно заинлайнится не смогут(может есть какаета другая реализация?).

Posix(не слышал так что воспользуемся linux):
    atomic_add();
    atomic_sub();
    atomic_inc();
    atomic_dec();
    
    Инлайнятся.
Говорить о assembler думаю не стоит, но если говорить то легче реализовывать под винду.
Раунд за Linux;
Так что счет 2:1.

4)Round "Thread local storage"

Win32Api:
    TlsAlloc();
    TlsSetValue();
    TlsGetValue();
    TlsFree();
    Без коментариев.
Posix:
    pthread_create_key();
    pthread_setspecific();
    pthread_getspecific();    
    pthread_delete_key();
    Без коментариев.

В это раунде нечья.

Так что счет 3:2.

5)Round Condition

Win32Api:
    InitializeConditionVariable();
    SleepConditionVariableCS();
    SleepConditionVariableSRW() - support only vista server 2008 не рассмотриваем.
    WakeAllConditionVariable();
    WakeConditionVariable();

    Я бы сказал не чего особого. Только вот не понятно как уничтожать.....
Posix:
    pthread_cond_init()
    pthread_cond_wait();
    pthread_cond_timedwait();
    pthread_cond_signal();
    pthread_cond_broadcast();
    pthread_cond_destroy();
    
    Функция с ожиданием по времени.
Так что Posix +1;

Так что счет 3:3.


Win32Api не имеет барьеров. Создание управление потоками не лучше чем у POSIX, CreateThread/_beginthread/_beginthreadEx по мне менее удобны чем pthread_create,
Хотя бы по тому что параметров не надо столько передавать. Здесь я не писал  о spin блокировках, read_write lock, в Win32Api это только в 
vista/server2008. Стоит отметить OpenMP но это принадлежит visual studio.

Я не селен в многопоточности, просто по изучать хотелось, так что любые замечание по теме буду только рад......

OpenMP Compilers


ЗЫ для чего вообще это сравнение? что оно дало? 

Это сообщение отредактировал(а) chaos - 6.3.2009, 07:34

Уточнение - серия trylock для Win32 API есть - это WaitForSingleObject с 0 в качестве параметра timeout
По поводу void* в качестве handle для Win32API - это ГОРАЗДО лучше, чем открытая структура у пользователя. Система должна сама заботится о защите своих объектов от несанкционированного вмешательства пользователя (да и от санкционированного тоже)
Далее, все серия Interlocked* в Win32API инлайнится компилятором, никаких dll не нужно (конечно, если программист не приложит больших усилий, что бы этого не было   )
В posix нет аналога Win32 Event'ов (очень убогий аналог - Conditional Variable)
В posix нет возможности ждать сразу на нескольких разных синхронизирующих примитивах.
По поводу TLS и там и там можно разложить переменные по TLS на этапе компиляции, и не пользоваться tls API совсем

Так что счет будет явно не в пользу posix.

xvr, но хоть это не очень хорошо, но всеже все это можно реализовать" используя то что есть.

" - уже реализовано, например монжо поглядеть в ACE.
ACE_Event & ACE_AutoEvent
на счет ждать нескольких событий, если я не ошибасюь то ACE_Reactor решит проблему. Наверника что-то есть уже готовое в boost::thread - но точно не знаю, не пользуюсь

Это сообщение отредактировал(а) chaos - 6.3.2009, 14:57

можно реализовать на Interlocked*** ф-ях, это довольно тривиально, к тому-же spin локи как правило не нужны, так как вместо этого обычно используют критические секции, для кр. секции можно указать spin count, в этом случае кр. секция будет работать как spinlock в режиме пользователя, пока не закончится spincount, а потом будет ожидание в режиме ядра

Можно конечно, на тех же CV. Но готовых нет   
У Win32 это все же элегантнее - там можно ждать на самых разных событиях. Конечно это можно реализовать где угодно, но накладные расходы будут немаленькие   

 
Спорный вопрос. Сколько *handle как проверить sizeof()? сколько я памяти использую?


 и как их сделать инлайн?


Я не думаю что это функциональноть дают право на победу, это легко реализуется, но пожалуй встроенное все таки элегантнее.

 будут, но не большие.

Нисколько. HANDLE на самом деле не указатель, а некоторый уникальный индекс, по которому ядро опознает свои объекты. Они в user space вообще места не занимают.
Они сразу инлайн:
Platform SDK, winbase.h

Угу, хочу ждать окончания процесса, чтения из pipe'а и события. Или дополнительный thread - это 'небольшие' расходы?