5 флопов - это ж по нынешним меркам что-то около нуля по времени. Учитывая, что интерпретатор PHP делает валидацию перед непосредственно исполнением скрипта, сомневаюсь, что такая схема вообще сработает.

А вызывающий скрипт не может сделать уведомление о запуске заранее? Ну, как вариант, конечно.

re_qas,

Исходную задачу опишите подробно. Возможно, найдется какой-то другой способ решения.

re_qasактивных сессий - 1500 +/-... период обновления - раз в 5 минут...Вот тут не вполне понятно. Обновлялка одна на все сессии или же у каждой сессии своя (вроде, отдельный запуск скрипта с определенными параметрами)?

В каком именно местеre_qasпо итогу проскакивают 3-4 дубля...?

re_qasодна.В смысле, должен произойти единственный запуск скрипта. Параметры запуска один раз вычислили и любая попытка запуска должна использовать именно их. Правильно понимаю?

re_qasвообще сложилось такое впечатление что 3-4 процесса (условно сервер 8 ядерный, пхп х86) срабатывают абсолютно параллельноСам по себе PHP однопоточный. Пока не запустишь отдельный процесс (форком или внешним скриптом запуска), не будет ничего параллельного. Конечно, есть вариант, когда при нескольких конкурирующих попытках запуска требуется обеспечить гарантировано один экземпляр запущенного скрипта. Тогда обычно использую такую пару строк:
У меня с этих строк по крону стартуют относительно долгоиграющие скрипты когда заранее невозможно определить предполагаемую продолжительность работы скрипта.

re_qasvkle

по логике должен сработать аналогично fopen(..,'x') если есть вернет false....Ну так fopen там (в первой строчке) и используется, только ориентирован он не на относительно медленное создание нового файла в ФС, а на обращение к уже существующему и прочитанному с диска (хранящемуся в файловом буфере) файлу. В этом смысле область такого использования несколько ограничена. Если правильно понимаю внутреннюю кухню PHP, в данном случае flock лишь вызывает системную функцию блокировки файла.

re_qasа если стоит raid-storage-claster то не может быть проблема в том что мой файловый разбит на несколько сервов?Полагаю, если каталог или цепочку каталогов, где создается файл, требуется читать с диска - возможно, это будет долгим процессом. Если каталог не вымывается из буфера ФС - вряд ли.

re_qasvkleпропущено...
В смысле, должен произойти единственный запуск скрипта. Параметры запуска один раз вычислили и любая попытка запуска должна использовать именно их. Правильно понимаю?именно этой части идет наличие по uri $bid через пост и проверка дольше только то этому одному параметру... само добавление ветвлится но на другие $bid перепрыгнуть не может - $bid - корень... новый появляется 4-10 раз в 5 минут... раз в 5 минут у всех 1500+ срабатывает запрос на обновление... этот запрос возвращает список $bid, по которому пинается скрипт на добавление по принципу кто первый от того и добавим - остальных нах...

Возможно, я бы сделал как-то так. Обозначу основные моменты.

1. Запуск единственного экземпляра основного скрипта. По крону или другим образом - не суть важно.
2. Там бесконечный цикл с проверкой нового $bid и sleep порядка нескольких десятков секунд исходя из условия "новый появляется 4-10 раз в 5 минут". Если проверка наличия нового не сильно ресурсожруча - можно и почаще проверять.
3. Если найден новый $bid - переходим в ветвь добавления/обновления.

Если само по себе обновление окажется процессом слишком длительным и не укладывается в приемлемое время - тогда, вероятно, сделал бы форк скрипта или (более вероятно) системный вызов с запуском скрипта добавления без ожидания завершения. Но тут надо дополнительно контролировать количество дочерних процессов, чтоб выше крыши не наплодить, так как без контроля в случае перегрузки сервера Load Average будет расти лавинообразно (процессы не успевают отрабатывать). Да, и у форка есть куча неожиданных и, порою, не совсем приятных особенностей.

Как-то вот в такую сторону стал бы смотреть.

re_qasпроверка "r+"... т.е. лишнее телодвижение процессора в части открыть и потом заблокировать,А вот и не угадали. :-)
Ибо сам __FILE__ (этот самый файл скрипта, который содержит эту строчку кода) в момент исполнения скрипта уже "открыт" - прочитан с диска и загружен в оперативную память совсем недавно. И, наверняка, сам файл или указатель на него ещё не был удален из буфера. Остается только сделать попытку исключительной блокировки.

re_qasvkleпропущено...
Полагаю, если каталог или цепочку каталогов, где создается файл, требуется читать с диска - возможно, это будет долгим процессом. Если каталог не вымывается из буфера ФС - вряд ли.попинаю завтра админа проверить где моя часть массива сидит... межсерверовая пинговка <1ms но если с запросом по файлу... то реально может быть косяк...Пингу (ICMP пакету) не требуется шкрябать головками дисков, так что, это совсем не показатель.

Заодно, чтоб два раза не бегать, поинтересуйтесь у админа о наличии на сервере локальной файловой системы типа memory и возможности доступа скрипта к ней. Нередко бывают какие-нибудь tmpfs с такой организацией размещения. Если файл блокировки делать там, оно, скорее всего, будет работать существенно быстрее.