Тормоза при совместном доступе к файлу.

[Mikle]

Делаю полигон для боев ИИ в крестики-нолики. Сервер запускается, открывает два файла для сообщений клиентам, запускает два выбранных клиента ИИ. Далее идет общение с клиентами через открытые с общим доступом файлы. Такая система выбрана из соображений простоты, чтобы в перспективе клиента можно было писать на любом языке, не сильно вникая в работу сервера.
Программы (и сервер, и клиенты) в режиме ожидания читают из файла команду, если команда не поступила - выполняют Sleep 50 и снова читают. При такой системе, почему-то, при запуске клиентов (Shell) сервер сильно притормаживает, а если в клиенте заменить цикл с Sleep на таймер с тем же периодом 50 ms, то срабатывает быстро, не пойму, в чем причина, разве Sleep не отдает управление системе?
Оба варианта прилагаются, можно сделать копию EXE клиента, а можно и не делать - запускать дважды один EXE и для крестиков, и для ноликов, проблем не возникает.
ИИ пока не прописан, клиент просто делает десять попыток поставить знак на свободное место, если на выходит - засчитывается проигрыш. Пока проверяется система связи.

[alibek]

Sleep замораживает основной поток программы.
Я бы советовал WaitForSingleObject. Либо с таймаутом INFINITE (или использовать Waiter! GSerg-a для этого), либо в цикле.

[Mikle]

alibek
На VB6 решение неплохо работает и на таймерах, но я хочу сделать максимально простой и отвязанный от VB вариант, чтобы устроить баталию на GameDev, и любой мог понять и перевести на свой язык мой исходник-образец.
Что есть WaitForSingleObject? API?
Если Sleep просто тормозит процесс, то почему тормозит только в начале, после загрузки клиентов тормоза пропадают.

[alibek]

Да, это API. Для ожидания более удобна, чем Sleep.
При запуске система много чего выполняет, возможно поэтому Sleep и тормозит. Если клиенты будут уведомлять сервер о том, что они запустились, и сервер запустит цикл ожидания только после получения такого уведомления, возможно тормоза исчезнут.

[Twister]

я хочу сделать максимально простой и отвязанный от VB вариант

Но вариант с обменом данными через файлы таковым далеко не является. Я бы сказал это порнография. В Windows для этого есть целый набор объектов - Именованые каналы, мэйл-слоты...
А вот фраза отвязанный от VB вариант меня "немного" убила - а что, VB предоставляет какие-то свои, обходящие систему, коммуникационные функции?

Для ожидания более удобна, чем Sleep

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

[Mikle]

Twister
Под словами "отвязанный от VB вариант" имелось ввиду, что его легко переводить. Sleep перевести значительно легче, чем вариант с таймером. Однако почему он тормозит, так и осталось загадкой.

[Хакер]

Mikle
В смысле тормозит?

При использовании таймера поток работает, и выполняется message-loop. Который обрабатывае очередь, в томи числе, таймер-события.

При использовании слипа поток тупо спит, ничего не происходит.

[Twister]

Под словами "отвязанный от VB вариант" имелось ввиду, что его легко переводить.

Наилучший вариант, в данном случае, это чистый WinAPI. Я бы рекомендавал тебе писать в файл с помощью обычной WriteFile - так легче будет потом перейти, к примеру, на связь через именованные каналы. А это сделать будет просто необходимо - иначе получится вполне добротная кустарщина.

[Mikle]

Хакер

При использовании слипа поток тупо спит, ничего не происходит.

А что, все запущенные VB приложения, это один общий поток?

[Хакер]

Mikle
Нет. Все запущенные приложения, это процессы. В каждом процессе по одному потоку.