Есть задача держать некторые данные, которые должны быть доступны для чтения и записи из нескольких разных процессов. Вроде file-mapping подходит для этой задачи. Но как быть, если процесс который был овнером (выполнил CreateFileMapping) завершился ? Получается остальные процессы уже не смогут читать писать в эту разделяемую память ? Как это можно обыграть ? И паралельно с этим, вопрос по синхронизации чтения/записи в эту область памяти. Я так полагаю самое разумное это мьютексы ? Т.е если происходит запись в облась памяти - "включать" мьютекс и затем, по завершении записи, - "отключать" ?
если процесс который был овнером (выполнил CreateFileMapping) завершился ? Процесс не является owner-ом объектов ядра. Получается остальные процессы уже не смогут читать писать в эту разделяемую память ? Смогут, если перед завершением процесса, поток которого создал file-mapping, какой-либо поток любого остального процесса открыл данный объект(т.е вызвал OpenFileMapping).
Да, хэндлы на объекты ядра поддерживают подсчет ссылок, так что объект не уничтожится пока имеется хотя бы один открытый хэндл.
Все зависит от того какая гибкость тебе нужна если взаимодействие будет происходить только между двумя процессами то вполне подойдет мьютекс/ивент, если процессов больше можешь заюзать LPC там предусмотрен механизм с секцией для передачи больших данных и с синхронизацией не будет мороки.
Синхронизация между большим кол-вом процессов обычно будет происходить. Все процессы равноправные и поэтому не хотелось бы применять технологию LPC, которая подразумевает клиент-сервер систему. Да и документации по LPC маловато. Получается вопрос о синхронизации чтения/записи остается открытый. Будут ли какие-то грабли при синхронизации между процессами с использованием мьютексов ? Когда мьютекс или евент получат сигнальное состояние, и несколько процессов будут ожидать это событие, какому-то процессу отдатся предпочтение ? Тому код которого процессор начнет исполнять первым(мб там очередь какая-нить выстраивается) ? Тогда как будет происходить этот процесс на многопроцессорной машине ? Ссори, много вопросов, хочется быть умным
почитай Джефри Рихтера "Windows 2000 для профессионалов", он оооч хорошо по этой теме писал, там прям раздел про мьютексы есть...
Собственно на сколько я знаю на многопроц. машинах проблем с ивентами/мьютексами нету, все дело в том как ты это реализуешь, и какова поставленная задача)
Partner В порядке захвата ожидания. Например, Рихтер (4-е издание), в предпоследнем абзаце Chapter 9. Thread Synchronization With Kernel Objects. Successful Wait Side Effects, пишет "In reality, the algorithm Microsoft uses is simply the popular "first in, first out" scheme. ... However, actions can occur in the system that alter this behavior, making it less predictable. ... One such action is a thread getting suspended. If a thread waits for an object and then the thread is suspended, the system forgets that the thread is waiting for the object. This is a feature because there is no reason to schedule a suspended thread. When the thread is later resumed, the system thinks that the thread just started waiting on the object."
Так в этой цитате Рихтер и пишет что само ожидание мютекса усыпляет поток... Хотя имхо в любом случае из юзермода делать предположения о работе планировщика и пытаться как то учесть результаты своих прогнозов задача неблагодарная. Тут имхо только играться с приоритетами потоков, хотя у меня XP SP3 (двухядерник) на конструкцию для замера тактовой частоты Код (Text): mov edi, @FUNC(GetCurrentProcess) invoke SetPriorityClass, edi, REALTIME_PRIORITY_CLASS mov esi, @FUNC(GetCurrentThread) invoke SetThreadPriority, esi, THREAD_PRIORITY_TIME_CRITICAL sleep 100 invoke SetThreadPriority, esi, THREAD_PRIORITY_NORMAL invoke SetPriorityClass, edi, NORMAL_PRIORITY_CLASS периодически (не всегда а ~ через 2 на 3 запуск) роняет программу - типа говорит нечего спать с таким приритетом ))
Y_Mur играться с приоритетами потоков Там же, на абзац выше: "... that thread priority has no effect: the highest-priority thread does not necessarily get the object."
Там такого не написано. Ждущий и суспендед поток, это разные вещи. Хотя в обоих случаях они не потребляют CPU.
Partner Разговор вроде о живых тредах Afaik гарантии, что потоки никто не усыпит - нет. lamer2k Imho схема синхронизация зависит от задачи. Твоя формулировка слишком размыта: "задача держать некторые данные, которые должны быть доступны для чтения и записи из нескольких разных процессов ... большим кол-вом процессов ... Все процессы равноправные". Например, можно использовать процесс, который будет формировать очередь, получая задания на чтение/запись от других процессов, и только он один будет выполнять чтение и запись.
