Добрый вечер. У меня такой вопрос: почему объектами CRITICAL_SECTION можно выполнять синхронизацию лишь среди потоков внутри одного процесса? Почему нельзя воспользоватся приемом отображения файлов для того чтобы 2 процесса имели доступ к одной и той же переменной CRITICAL_SECTION и использовали ее для синхронизации собственных потоков?

потому-что для этого существуют именованые мьютексы  

потому что тогда те чуваки из microsoft, которые реализовали мьютексы в winapi, получается тратили свое рабочее время на ненужную функциональность. думаю, им бы не понравилась такая характеристика.

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

Добавлено @ 22:46
Представляю 2 процесса:
Первым запускается процесс А.
Process A:
#include <windows.h>
#include <tchar.h>
#include <process.h>
#include <iostream>

using namespace std;

CRITICAL_SECTION *lpCrtSct;

unsigned int WINAPI threadFunc(void *arg)
{
    EnterCriticalSection(lpCrtSct);

    for(int i = 0; i < 5; i++)
    {
        Sleep(1000);
        cout << "a ";
    }

    cout << endl;

    LeaveCriticalSection(lpCrtSct); // глючит тут: First-chance exception at 0x7c964ed1 in 8_8_1.exe: 0xC0000008:       //An invalid handle was specified.
    
    return 1;
}

int main()
{
    HANDLE hFile = CreateFile(_T("F:\\map.txt"), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ |                                          FILE_SHARE_WRITE,  0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); 
    
    int option;
    HANDLE hndl;

    HANDLE mFile = CreateFileMapping(hFile, 0, PAGE_READWRITE, 0, 64, _T("m"));

    lpCrtSct = (CRITICAL_SECTION *)MapViewOfFile(mFile, FILE_MAP_ALL_ACCESS, 0, 0, sizeof(CRITICAL_SECTION));

    InitializeCriticalSection(lpCrtSct);

    cout << "begin? ";
    cin >> option;

    if(option == 1)
    {
         unsigned int id;

        hndl = (HANDLE)_beginthreadex(0, 0, threadFunc, 0, 0, &id);
            WaitForSingleObject(hndl, INFINITE);
    }

    return 1;
}
Этот процесс производит отображение файла, записывая в него значение *lpCrtSct

Process B:
#include <windows.h>
#include <tchar.h>
#include <process.h>
#include <iostream>

using namespace std;

CRITICAL_SECTION *lpCrtSct;
unsigned int WINAPI threadFunc(void *arg)
{
    EnterCriticalSection(lpCrtSct);

    for(int i = 0; i < 10; i++)
    {
        Sleep(1000);
        cout << "b ";
    }

    cout << endl;

    LeaveCriticalSection(lpCrtSct);  

    return 1;
}

int main()
{
    HANDLE hFile = CreateFile(_T("F:\\map.txt"), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE,
                              0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); 
    
    int option;


    HANDLE mFile = CreateFileMapping(hFile, 0, PAGE_READWRITE, 0, 64, _T("t"));

        //lpCrtSct указывает на тоже значение используемое в Process A.
    lpCrtSct = (CRITICAL_SECTION *)MapViewOfFile(mFile, FILE_MAP_ALL_ACCESS, 0, 0, sizeof(CRITICAL_SECTION));


    cout << "begin?";
    cin >> option;

    if(option == 1)
    {
        unsigned int id;

        HANDLE thrdHndl = (HANDLE)_beginthreadex(0, 0, threadFunc, 0, 0, &id);
        WaitForSingleObject(thrdHndl, INFINITE);
    }

    return 1;
}

Это сообщение отредактировал(а) ChiciucMaxim - 16.7.2008, 22:50

похоже, ты знаешь что-то, чего не знает больше никто (кроме ребят из MS ну и пожалуй Соломона с Руссиновичем)

Потому что Handle`ы  OwningThread и  LockSemaphore в рамках одного процесса
не имеют никакого смысла в рамках другого. 
Даже если попробовать во втором процессе "продубликатить" (DuplicateHandle)
LockSemaphore и насильно его запихать в CRITICAL_SECTION, то это ничего не даст,
ибо OwningThread будет фиксироваться автоматически Handle`ом валидным только в рамках
того процесса, которому принадлежит нить, захватившая ресурс.
Вот такое мое IMHO 

По теме: почитай Рихтера. Если мне не изменяет память, главы 8-10.
Там он подробно описывает (и создает) "критическую секцию" (название такое же, но струтуры разные)
 для межпроцессорного взаимодействия.

С обычным мьютексом код намного компактнее ;)

Не смею с Вами спорить 
Если честно, то детально я не разбиралась с межпроцессорной синхронизацией (не было необходимости),
но в защиту Рихтера, рискну предположить, что его код окажется на порядк(и) "быстрее".
Чтобы вынести более точный вердикт, необходимо тщательное изучение, что он там делает и почему,
а не "галопом по европам" как я   
С подобными вещами (оптимальностью кода) я сталкивалась на других его примерах.