почему же?

щас еще вроде амазон выкатил свою версию крайенджина (лесопилка или лесоруб, что-то такое)

Fez, Meat Boy, Minecraft, Hotline, Braid etc

Что у них общего с Принцем? Графика современная (в смысле, что не ручная пикселизация), писаны не на ассемблере.

Можешь показать современную инди-игру эквивалентную «Принцу» про которую хоть кто-то кроме автора слово замолвит?

Назвал. В чем проблема?

А я несколько раз писал «Тетрисы», «Питоны»

Ну до вашего тетриса и питона конечно не дотягивают.

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

Смотря что ты за человек вообще и во что играешь. Может это не твое.

Ну и сколько лет она делается? Я не спорю, что можно и свой движок написать, как например, поступил Фил Фиш со своей Fez. Но как бы он и сам потом признал, что лучше бы выбрал Unity.

Но он все-таки ее доделал (довольно быстро) и Fez получился классным! А 0 A.D. сколько делают? 20 лет почти? И все альфа? это же ппц.

А почему не сказано, свободная игра или нет? По-моему это очень важно. Если не свободная — то зачем на неё тратить средства, лучше какую-нибудь свободную поддержать.

А есть для инди что-то более лучшее?

Ну например движок Flare или Battle for Wesnoth.

Ну и каким боком это можно прикрутить к трёхмерной аркаде с упором на историю? IMHO сейчас главное в играх всё-таки хоть сколько-нибудь приличный графоний, или крепкая история, или затягивающий геймплей, а вовсе не кодинг и в частности Unity (или любой другой коммерческий движок с поддержкой и обучающей литературой на все случаи жизни) даёт возможность посредственному программисту с хорошей идеей создать хоть что-то приличное за разумный промежуток времени.

В будущем кодировать будут исключительно роботы. Думать скорее всего тоже. Не очень понятно будут ли люди...

Можешь показать современную инди-игру эквивалентную «Принцу» про которую хоть кто-то кроме автора слово замолвит? :)

Legend of Edgar — отличный платформер, под GNU/Linux. Свободный, включая ресурсы.

Проблема в том, что с поддержкой свободных игр на краудфандиговых ресурсах весьма и весьма грустно. Вкратце: не поддерживают за ооооочень редким исключениями. Люди существа в большинстве своём корыстные и это на самом деле во многих случаях очень даже не плохо.

прикольно, зашел посмотрел и купил Lifeless Planet, зачем не знаю, пусть будет :) За последние пару лет 45 игр куплено, еще ни в одну не играл, вернее играл в пиратки, в купленные нет.

после 20 светолет криосна

Даа, 65 парсек ожидания это мощно.

Вообще-то парсек больше светого года, примерно в три раза, так что нужно было делить 20 на 3.2616, а не умножать

Да, все так. Но спич был не о том.

Типа пытаешься намекнуть, что время не в метрах измеряется? Я в курсе. Воспринимай фразу, как «космонавт и два его товарища пролетели 20 светолет, при этом большую часть пути команда находилась состоянии в криогенного сна»

после 20 светолет криосна

Даа, 65 парсек ожидания это мощно.

Ну, «300 километров сна в автобусе» мало же кого смущают :)

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

Смотря что ты за человек вообще и во что играешь. Может это не твое.

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

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

Я знаю, что это не так - и это достаточно легко понять, поскольку даже компилятор может свободно переставлять инструкции, «размазывая» инструкции конструктора или вызывая конструктор между другими инструкциями (в том числе и пересекая передачу ссылки на ещё не созданный полностью объект между потоками, например, через атомики с memory_order_relaxed).

Но если вдруг ты чудом увидишь что-то, что откроет мне глаза, то процитируй стандарт. Ссылок на творчество и код «авторитетов» не нужно - достаточно стандарта C++11 и новее.

И тогда уже поговорим. А читать бредни балаболов, которые обвиняют меня во лжи, как и отвечать на эти бредни, я не буду.

Но если вдруг ты чудом увидишь что-то, что откроет мне глаза, то процитируй стандарт.

http://eel.is/c draft/thread.mutex#requirements.mutex-5.note-2

1) Because the default constructor is constexpr, static mutexes are initialized as part of static non-local initialization, before any dynamic non-local initialization begins. This makes it safe to lock a mutex in a constructor of any static object.

Но информация ценная. Нужно подумать. Возможно, нужно использовать явно статический мьютекс.

2) Это вообще не связано с придуманной специфической ролью конструкторов в многопоточных программах.

А у тебя static mutex?

Нет. И, видимо, у меня это нужно исправлять. Это интересное ограничение на мьютексы. Как всегда в плюсах - фича есть, но пользоваться невозможно. Нормальные thread-safe классы писать с такими мьютексами затруднительно.

Вероятно, нужно свой мьютекс нужно городить с thread-safe конструктором. Только и атомики в плюсах тоже такие же без гарантий создания. Так что не на них нужно это делать.

А вот пример из стандарта про конструкторы, полный аналог того, что я давал выше. http://eel.is/c draft/atomics#types.operations-3

И, видимо, у меня это нужно исправлять

static mutex в конструкторе и методах тебе не поможет, ибо http://eel.is/c draft/basic.life#7, http://eel.is/c draft/basic.life#7.2

... before the lifetime of an object has started ..., any glvalue that refers to the original object may be used but only in limited ways. ... The program has undefined behavior if:

— the glvalue is used to call a non-static member function of the object

Мне не поможет потому что не захочу статический мьютекс для такого случая.

А так сам мьютекс не может нестатические функции вызывать. А в конструкторе объекта лочиться на статический мьютекс можно, потому что он гарантированно в инициализированном (видимом) состоянии.

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

Дополнительная синхронизация, чтобы прочитать мьютекс, и потом уже синхронизироваться на мьютекс через три инструкции - это сильно.

В общем нужна будет дополнительная синхронизация в этих условиях.

Ага. Внешняя. Как при создании синглтона.

Наконец до тебя допёрло.

До меня допёрло то, что пошарить мьютекс между уже живыми потоками невозможно без дополнительных накладных расходов постоянного действия. И даже с такими расходами это гемор. Сделаю свой мьютекс, а std::mutex отправлю на свалку.

Багрепорт засчитан.

О святой роли конструкторов в потокобезопасности (т.е. её отсуствии) - http://eel.is/c draft/atomics#types.operations-3 Синхронизация там нужна. Без неё thread-safety не будет. И да - внешняя синхронизация означает отсутствие у класса свойства thread-safe. Привет Вильямсу и Ко.

Сделаю свой мьютекс, а std::mutex отправлю на свалку

Твой мьютекс, если ты его также будешь хранить в объекте и лочить из конструктора и других методов, тоже не поможет. См. выше про лайфтайм. «Увидеть» инициализацию нужно ДО вызова любого метода, а не во время. Иначе UB.

внешняя синхронизация означает отсутствие у класса свойства thread-safe

К классу не применимо свойство thread-safe. Оно применимо к отдельным методам класса. И конструктор к ним не относится, т.к. не может вызываться одновременно с остальными методами в принципе.

Нет никаких методов в плюсах. А в рантайме - тем более.

К классу не применимо свойство thread-safe. Оно применимо к отдельным методам класса.

Я не собираюсь обсуждать проблему visibility на уровне методов и прочего синтаксического сахара. Если необходимо обеспечить гарантии видимости состояния объект как инвариант, то цитата выше становится бессмысленной.

Вот тут вся информация как можно проверить выполнение или невыполнение этого инварианта: http://eel.is/c draft/intro.multithread

И мой мьютекс, хранящийся в объекте, можно провалидировать формально по этим требованиям. Чем я и буду заниматься вместо разговоров о методах.

И да - конструктор может вызываться одновременно с остальными «методами» в принципе. В третий раз ссылка из стандарта:

http://eel.is/c draft/atomics#types.operations-3

Цитирую явно:

It is possible to have an access to an atomic object A race with its construction

За сим раскланиваюсь.

конструктор может вызываться одновременно с остальными «методами» в принципе.

Когда я говорю «в принципе» — я подразумеваю well-formed program, без UB. Если ты про то, что написано в Note, то там в конце сказано, что «This results in undefined behavior.»

За сим раскланиваюсь.

Нет мочи терпеть батхёрт от того, что весь твой код — сплошное UB? Так-то. Прежде чем дуть щёки и называть знающих людей «балаболами», убедись 7 раз, что не испачкал себе штаны.

Нет никаких методов в плюсах. А в рантайме - тем более.

Ха-ха-ха-ха. Так я и думал.

Сначала «покажи мне формально, по стандарту», а потом «я вам не верю, вы всё врёти, в рантайме этого нет, значит не UB!11».

utf8nowhere задал верный вопрос про неинициализированный мьютекс.

Дело не в мьютексе. Даже если лочить/анлочить в конструкторе и методах глобальный (а значит заведомо инициализированный для всех) мьютекс, UB останется UB, т.к. без доп. синхронизации методы будут вызываться у объекта, чей лайфтайм ещё не начался.

кто-то ещё играет в компьютерные игры?

да я понял о чём ты, я думаю: в моём коде в том треде как раз так и есть - внешний мьютекс и всё равно НП.

Оно и понятно в общем то, если объект инициализируется вызовом конструктора, то нельзя использовать объект до того как отработал конструткор. И никакие внутренние мьютексы не помогут здесь. А внешние помогут только если помогут гарантировать очерёдность: «сначала конструктор, потом как хотите»

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

Ещё раз кракто:

1) нет святой роли конструктора в многопоточности

2) но есть святая роль конструктора в инициализации

3) из чего следует что первичность инициализации нужно обеспечивать внешними средствами в многопоточном коде

4) я тебе привёл пример кода который показывает что в мьютексе (даже правильно работающем) смысла нет в конструкции которую ты считаешь правильной. Ты же продолжаешь упираться, не умея то ли читать, то ли признавать свои ошибки.

5) я _полагаю_, ты перепутал 1) и 2) и поэтому тебе кажется что тебя убеждают в святой роли конструктора в многопоточности.

---------

более подробно

Ты никак не можешь понять, никто не считает что конструктор чем то выделяется с т.з. многопоточности. Наоборот, он не выделяется. Но необходимо обеспечить вызов конструктора _до_ любого обращения к любому члену/методу создаваемого объекта.

А раз у конструктора нет никакого выделенного поведения относительно многопоточности, то единственный способ обеспечить такую очерёдность - это использование внешней синхронизации.

Я тебя ещё раз прошу привести пример кода в котором мьютекс (в том виде в котором ты его используешь/хочешь использвать) решал бы проблему, а отсутсвие мьютекса - вскрывало бы проблему.

И/или обрати внимание всё таки на мой код - там внешний заведомо рабочий мьюекс и всё равно UB при попытке подобной синхронизации.

Правильный ответ

Вот это я понимаю ответ. Поддерживаю

Читать про барьеры памяти, OoO execution, когерентность, оптимизации компилятора, C++ memory model до просветления.

У тебя в коде нужно placement new использовать, poor man. А проблема, которую ты хочешь показать, на amd64 без помощи компилятора не воспроизводится в принципе. Потому что на этой архитектуре sequentially consistent memory model.

#include <iostream>
#include <thread>
#include <mutex>
#include <chrono>
#include <stdexcept>

using namespace std;

void doLongThing() {
  cout << "starting long initialization of class MyTestTread" << endl;
  this_thread::sleep_for(chrono::seconds(2));
  cout << "long initialization of class MyTestTread has finished" << endl;
}

class MyTestTread {
public:
  MyTestTread(void) {}
  MyTestTread(const bool useMutex, mutex &_mutex) { // : m_mutex() {
    cout << "flag: " << flag << endl;
    if(useMutex) {
      lock_guard<mutex> lock(_mutex); // synchronising memory
      cout << "using mutex" << endl;
      doLongThing();
      flag = 2;
    } else {
      cout << "do not use mutex" << endl;
      doLongThing();
      flag = 2;
    }
    
    cout << "flag: " << flag << endl;
  }
  
  ~MyTestTread(){}

  void checkProblemAndPrintMessage(mutex &_mutex) {
    unique_lock<mutex> lock(_mutex);
    cout << "flag: " << flag << endl;
    if(flag == 2) {
      cout << "\t---== No probs man, it's all right! Congratulations! ===---" << endl;
    } else {
      cout << "\n\t---=== Poor poor man, something definetely went wrong... how flag could be " << flag << " in this moment? Only the way is we have undefined behaviour here. I think. ===---" << endl << endl;
    }
  }

private:
  // mutex m_mutex;
  int flag = 0;
};

mutex m;

void createAndInit(MyTestTread *t, const bool useMutex) {
  // this_thread::sleep_for(chrono::seconds(1));
  new (t) MyTestTread(useMutex, m);
}

void callCheckProblem(MyTestTread *t) {
  // just make sure order is always the same... 
  // if delete this line, results are about the same, but order of calling constructor and checkProblemAndPrintMessage can be different
  this_thread::sleep_for(chrono::seconds(1));
  t->checkProblemAndPrintMessage(m);
}

int main(int argc, char* argv[]) {
  string argv1(argv[1]);
  if(argc != 2 || (argv1 != "mutex" && argv1 != "nomutex")) {
    string p1("usage:\n\t- either\t");
    throw invalid_argument(p1 + argv[0] + " mutex\n\t- or\t\t" + argv[0] + " nomutex");
  }
  
  bool useMutex(argv1 == "mutex");
  MyTestTread t;
  
  thread t_createAndInit(createAndInit, &t, useMutex),
         t_callCheckProblem(callCheckProblem, &t);

  t_callCheckProblem.join();
  t_createAndInit.join();
}

$ ./a.out mutex
flag: 0
using mutex
starting long initialization of class MyTestTread
long initialization of class MyTestTread has finished
flag: 2
flag: 2
	---== No probs man, it's all right! Congratulations! ===---

Ещё раз - вся инфа есть в C++ memory model.

За выявление убогости стандартных плюсовых мьютексов благодарю. Только к святой роли конструкторов это не имеет никакого отношения. Фактически, такие мьютексы почти невозможно нормально передать между потоками (потому что нет базовых thread-safe механизмов синхронизации), и они обречены на то, чтобы быть убогим говном. На атомиках можно организовать безопасную передачу, но это каждый раз нужно городить небольшую кучку малочитабельного кода.

Хотя даже на amd64 + g++ -O0 для a.out nomutex poor man воспроизвелся. Но смотреть асм листинги компилятора почему flag=2 не виден без мьютекса нет ни времени ни желания.

С a.out mutex проблем нет. Есть проблема только с самим уродцем std::mutex.

Понятно почему там flag=0 для nomutex. Так тупо заложено в самой программе.

В общем, на будущее: на amd64 проблемы visiblity тестировать - дело неблагодарное. Большинство из них не проявляются. В большинстве своём проявляются только проблемы, наведённые оптимизациями компилятора, UB, и non-atomic reads/writes.

А остальное - в стандарте C++.

На всё остальное можете засчитывать слив, ибо обсуждать что-то на уровне «методов» я не буду. Компьютеры и компилятор C++ так не работают.

Флаг СШП на спине

Да пошел он нахрен.

обсуждать что-то на уровне «методов» я не буду. Компьютеры и компилятор C++ так не работают.

Задолбали уже люди, которые не умеют формально рассуждать о выполнении кода.

Поддержка GNU/Linux заявлена

Ну сколько раз вас уже наё? Опять выпустят без поддержки Linux и скажут, что для одного процента ничего делать не будут, а ещё что типа драйверы видеокарт плохие.

На сколько я понимаю, если код однопоточный, то мьютекс в конструкторе (в той форме в которой ты его туда тулишь) не нужен, это верно?

Однопоточный код sequentially consistent - синхронизация там не нужна ни в каком виде. Синхронизировать нужно только inter-thread communication.

Извращённый вариант - синхронизировать доступ к пошареным системным ресурсам (файлам и файловым дескрипторам, shared memory, базе данных, etc) может быть нужно и в однопоточном коде. Но это к теме многопоточности не относится.

Ну, гляди:

Я тебе показал существование по крайней мере одной проблемы, которую _не_ решает мьютекс в конструкторе.

Мьютекс вне конструктора делает код «однопоточным» и решает все проблемы.

Вывод: мьютекс внутри контсруктора - бессмысленен, потому как существует по крайней мере одна проблема которую он не решает и которая ведёт к НП.

------

Вообще я совершенно не понял что ты сделал с кодом: задача была - показать существование проблемы и возможность/невозможность её решения с помощью мьютекса. Что мой код и делал. Ты его «исправил» обойдя проблему. Смысл? Это как раз то чего делать не надо было, поскольку это противоположно поставленной задаче. Возникает ощущение, что ты не понимаешь контекста дискуссии. (Способ «обхода» - "-O0" - вообще вне критики, ну да бог с ним).

Мьютекс что внутри конструктора, что вне конструктора работает одинаково. Бери ассемблерный листинг и смотри выхлоп компилятора.

А многопоточность вне контекста модели памяти процессора/языка я не обсуждаю.

И да - в твоём коде был баг, который я исправил. Ты читал флаг из указателя в пустоту. Смотри diff между своим кодом и исправленным от меня, пока не поймёшь.

Больше я в этом треде не участвую. Утомили.

Даже не так - разберись сначала, что именно делает твой код, и почему именно он не работал (проблема вообще не с многопоточностью). Это сделай обязательно.

Потом почитай семантику многопоточных программ в C++ по ссылке на стандарт выше, и потом будешь мне открывать глаза на то, как мьютекс в конструкторе ничего не делает в отличие от мьютекса, который идёт сразу же после конструктора.

g++ -O0 вообще не про фиксы был. Почитаешь про C++ memory order - поймёшь. А пока что мы разговариваем о многопоточности в плюсах как инженер-электрик и балерина о проблемах ядерной физики. Мне такие разговоры ни к чему.

отличие от мьютекса, который идёт сразу же после конструктора

Можешь объяснить кто тебе предлагал мьютекс который идёт «сразу же после конструктора»? А то как то стрёмно, ощущение что ты сам с собой разговариваешь, но почему то при этом отвечаешь на мои сообщения...

Хотя ладно, можешь не объяснять, тут конечно авгиевы конюшни говна в голове... я не Геракл всё таки, иди пиши своё UB дальше. Вольному воля, как говорится.