Почему запуск процесса через CreateProcess() может очень медленно выполняться?

1. Какой размер исполняемого файла запускаемого процесса? Если большой, то при загрузке могут быть тормоза. Но по идее повторный запуск уже должен быть быстрее (если файл влазит в кэш ОС)
2. Как замеряли время? Конкретно время выполнения CreateProcess() или всего приложения?
3. Предполагаю, что висит у вас на выполнении WaitForSingleObject() - это единственное место, где в коде происходит ожидание. Попробуйте тут поэкспериментировать, напримре, вместо INFINIT задать какое-то мелкое время или вообще не ждать.
Похоже в коде на go, не происходит ожидание завершения дочернего процесса.

В школьном вай фае заблокирован порт 9. Как обойти блокировку?

azim218,

Как я понял заблокированы все порты кроме 443

Общий ответ: иди к админу договариваться.
UDP/9 порт - это видимо Wake-On-LAN. Формально это, конечно discard, но на практике WOL его использует.

Если хост получатель внутри сети - к админу.
Если хост получатель в интернете - могут быть варианты с промежуточным ВПНом по 443 порту и через него выход на хост получатель по 9 порту.

Почему я могу изменять состояние объекта хранящийся в const std::unique_ptr и const std::shared_ptr?

maaGames,

const int* p1 = ...; // константный указатель
int* const p2 = ...; // указатель на константу

Наоборот же.
p1 - изменяемый указатель на константный объект,
p2 - константный указатель на изменяемый объект

p1 и p3 еще могут быть записаны так:

int const * p1;
int const * const p3;

Можно ли использовать не парные Acquire/Release порядки памяти?

jcmvbkbc,

cppreference ничего не говорит про видимость, только про атомарность, т.е., что изменение происходит целиком или не происходит вообще.

Интересная мысль :)
В таком случае, ТС в 3 нужен ACQUIRE.

Все таки вредно сидеть на х64, он слишком много прощает в плане использования атомарных операций.. Атомарные структуры видимо лучше отлаживать на ARM.

Как всегда, с вами поучительно пообщаться. Спасибо!

Можно ли использовать не парные Acquire/Release порядки памяти?

jcmvbkbc,

из чего это следует?

https://en.cppreference.com/w/c/atomic/memory_orde...
Объяснение к memory_order_relaxed

Что здесь обозначено словом "синхронизировать"?

Тем или иным способом сделать видимыми данные для других потоков после записи (и перед чтением). Барьеры acquire/release или seq_cst.

Какие выводы можно сделать из такого теста, если он не показывает ощибок?

Если ошибок нет, то, вероятно, очередь работает правильно. Гарантии, конечно, не дает, т.к. возможно ситуация при которой возникает ошибка не появилась в конкретном прогоне.

Можно ли использовать не парные Acquire/Release порядки памяти?

Eugene Usachev, relaxed обеспечивает только видимость изменений самой атомарной переменной в других потоках.

В методе producer_maybe_push() нужно синхронизировать данные только после записи (new), это происходит в 4. Head и tail синхронизируются благодаря атомарным операциям. Следовательно в 3 можно использовать relaxed.

Чтоб совсем все было понятно можно использовать relaxed везде для доступа к значениям head и tail. Но добавить "ручной" atomic_thread_fence перед чтением данных и после записи данных с соответствующим упорядочиванием acquire/release. Так вы отделите синхронизацию собственно данных от синхронизации head и tail и будет проще разобраться с тем, что происходит на каждом этапе.

Сделайте тест и погоняйте его несколько часов с разным количеством узлов. В тесте предусмотрите проверку правильности операций - подсчитывайте количество pop/push операций, а так же считайте какие-нибудь суммы по данным и в конце теста сравнивайте количество и суммы для pop и push - они должны быть равны.

Почему окружность получается отрисованной не ровно?

Лесенка будет всегда при достаточном увеличении, но кое-что сделать можно:
Использовать double для вычисления радиусов и косинусов/синусов.
К float приводить (FPoint) только окончательно вычисленное значение, все промежуточные в double.
Увеличить количество точек для отрисовки фигуры.

Какой есть софт для общей папки (3-5 пользователей Windows в локалке)?

Про пользователей уже написали. Разберитесь почему "периодически отваливается" и будет вам счастье.
Вообще это самый надежный инструмент для локальной сети из всех тут приведенных. Им пользуются очень большие корпорации, сидящие на винде, там правда используют АД для авторизации, но сам протокол один и тот же.

По отваливанию можете тут задать вопрос с приведением каких-то фактов, ошибок в журналах и т.п.

Несколько советов, чтоб не отваливалось:
1. Попробуйте подключать шару не по имени компьютера, а по IP адресу. IP адрес на компе, где расшарен диск должен быть статическим в этом случае.
2. Если не поможет п.1. Возможно проблема в появлении в одноранговой сети двух master browser. По идее, должен быть только один комп с такой ролью (процедура выбора master browser запускается виндой автоматически и незаметна для пользователя), но в одноранговой сети микрософт бывают подобные флюктуации. Проблема давно известная. Присвоение роли master browser можно настроить руками, об этом есть статьи в интернете.

Как открывать батник скрытно?

utsiye, Я имел ввиду другой вариант, но так даже лучше, если у батника нет других целей.

Как открывать батник скрытно?

Конечно не наследуется.
Можете так же открывать питоны через тот же vbs, поменяв командную строку.
Можно даже немного подправить и использовать один и тот же VBS, передав команду в параметре к нему, что бы не плодить пачку по сути одинаковых vbsов.

Как на VPS сервере нажать чтобы файл сохранился?

Dima_E, Подобный вопрос возникает у каждого, кто случайно запускает vim, думая, что это обычный текстовый редактор в стиле Windows notepad.
Но vim не совсем обычный текстовый редактор. Он управляется командами (как bash например), которые вводятся в его "командной строке". У него есть несколько режимов работы и т.д. и т.п. Даже запись изменений и выход из vim - это отдельные команды.
Если хотите освоить vim стоит почитать какой-нибудь мануал и потренироваться, например тут или тут.
Даже для простых действий (открыть/сохранить/закрыть файл) требуется знание базовых основ работы vim.
vim - очень мощный редактор, но с порогом входа выше, чем ms word или windows notepad.

Есть ли смысл в handles вместо сырых указателей для аллокации памяти в embedded устройствах?

Catmengi,

2 потока не могут одновременно блокировать handle

Это лишнее, на мой взгляд. Это должно решать приложение. С таким подходом вы заранее объявляете все данные в куче разделяемым ресурсом, даже если они не являются такими (вышестоящее приложение однопоточное).
Ваш мьютекс должен использоваться только для переноса памяти в другое место. Тут больше подойдет rwlock, где read блокировка будет захватываться потоками при доступе к данным, а write блокировка - дефрагментатором.

Есть ли смысл в handles вместо сырых указателей для аллокации памяти в embedded устройствах?

Catmengi, huid для 8 Мб хватит и uint32 за глаза.
А где же мьютекс?

Есть ли смысл в handles вместо сырых указателей для аллокации памяти в embedded устройствах?

А вы планируете вытесняемую многозадачность реализовывать или кооперативную? Ядер сколько на вашей железке?
При вытесняемой надо будет блокировать хэндл на мьютексе при попытке доступа к памяти по нему и освобождать после доступа.
В кооперативном варианте на одном ядре этого, видимо, можно избежать. На нескольких ядрах уже начнется конкуренция.

Есть ли смысл в handles вместо сырых указателей для аллокации памяти в embedded устройствах?

Catmengi, Какие например метаданные могут быть не известны в compile time?
Если пользователю понадобятся добавить к хэндлу свои данные, то он просто объявит свою структуру, хэндл и метаданные положит в эту структуру. В общем как обычно делаются обертки вокруг системных функций.
Вообще в хэндле в качестве метаданных будет некая информация, которая будет необходима вашему дефрагментатору для работы. С их набором вы определитесь, когда будете его писать.
Пока же можно просто положить в структуру хэндла указатель на реальные данные.

Есть ли смысл в handles вместо сырых указателей для аллокации памяти в embedded устройствах?

Catmengi,

но от маленькой долго живущей аллокации в середине кучи он не защитит

Для дефрагментации "на лету" хэндлы выглядят нормальным решением.

Есть ли смысл в handles вместо сырых указателей для аллокации памяти в embedded устройствах?

Catmengi, Если массив хэндлов выделять динамически в той же куче, то он сам будет попадать под операцию дефрагментации и может быть перемещен дефрагментатором и тогда все хэндлы станут не действительны.
В таком случае вам, видимо, надо будет делать 2 кучи. Одну по меньше для разных "системных" нужд, где память не будет принудительно дефрагментироваться и где аллокатор будет выдавать прямые указатели. И вторую на которой будет работать дефрагментатор и память будет выдаваться через хэндлы.
Ну или как-то по другому это обходить.
Думаю, что массив хэндлов, который нельзя перемещать, окажется не единственным подобным объектом в вашей системе.

Есть ли смысл в handles вместо сырых указателей для аллокации памяти в embedded устройствах?

А где будете выделять память под handles? Судя по описанию это должен быть какой-то статический массив фиксированного размера не в общей куче.
Для борьбы с фрагментацией идея выглядит здравой. Но с другой стороны, возможно, лучше использовать какой-то аллокатор, в котором уже реализована логика дефрагментации.

Как ждать в диапазоне атомарных чисел?

Интересно зачем в С++20 добавили в атомарные объекты блокирующий метод wait?

Как ждать в диапазоне атомарных чисел?

Павел Соколов, Если нужно читать данные в разных потоках, которые иногда изменяются 1 потоком, то можно сделать примерно следующую схему:

void writer(data d) {
  atomic_fetch_add(v1, 1);
   write(d);
  atomic_fetch_add(v2, 1);
}

data reader() {
  int lv1, lv2;
  data d;
  do {
    lv2 = atomic_load(v2);
    d = read();
    lv1 = atomic_load(v1);
  } while(lv1 != lv2);
  return d;
}

Счетчики циклов записи последовательно инкрементируются писателем. При чтении операция может считаться успешной, только если считанные счетчики циклов записи равны (т.е. при чтении в промежутке не было операции записи). При этом важен порядок инкремента и чтения счетчиков.
Если операции записи будут не частыми, то чтения почти всегда будут завершаться за одну итерацию.
Этот подход подсмотрел при чтении NTP демоном GPS данных при работе GPS источника времени.

В этой схеме теоретически поток записи может быть вытеснен в процессе записи (после инкремента v1) на достаточно долгое время. Но если все потоки имеют один и тот же приоритет, то поток записи получит свой процессор. Так же можно при чтении на повторных циклах вызывать yield(), чтоб ускорить возвращение потока записи в работу. Но это не обязательно, в типичных случаях схема работает и в таком виде.

Сами по себе операции чтения и записи должны быть достаточно короткие, никакого ввода/вывода и т.п. долгоиграющих операций, только чтение/запись памяти. Если это условие не соблюдается то rwlock вам в помощь.

Для еще большего ускорения можно поиграть с explicit вариантами атомарных функций и указания memory order вручную - на v1 может быть установлен relaxed порядок, на v2 acquire/release.
Так же стоит разнести в памяти v1 и v2 друг от друга минимум на размер кэшлинии (обычно 64 байта), это предотвратит не нужные синхронизации, которые появятся, если v1 и v2 попадут в одну кэш линию. Это еще придаст буста операциям.