Frage zu Multithreading in ArmA

Hoegnison · 1. August 2015

Gude,

ich habe mich die letzte Zeit ein bisschen mit Multithreading beschäftigt und finde das Thema recht interessant. Auch in ArmA könnte man sicherlich einige Bugs vermeiden, die ungewollt durch die Nutzung von mehreren Threads auftreten.
Meine Frage ist:
Hat sich jemand bereits damit auseinander gesetzt und hat vlt schon den ein oder anderen Workaround. Vielleicht hat auch jemand dezidiertes Wissen, wie der Scheduling Algo von ArmA funktioniert.
Ansonsten weiß vielleicht jemand wie man in ArmA einen Mutex oder eine Semaphore realisieren könnte oder ob es eine Möglichkeit gibt atomar zu lesen und dann zu schreiben?

Gruß und schönes WE!

X39 · 1. August 2015

welche "bugs" willst du als anwender denn druch multithreading vermeiden (zudem ist mir neu das durch multithreading bugs vermieten werden :P)

der scheduler in arma funktioniert recht einfach:
ein thread, mehrere skripte
also:
ausführen --> pause --> nächstes
oder anders:
spawn ist synchron jedoch nicht im selbem skript handle

was du mit mutex und semaphor in SQF kontext meinst ist mir jedoch nicht bekannt (wenn du daten in c/c++ aus arma lesen willst und somit SQF quasi umgehen ... good luck beim reverse engineering)

Hoegnison · 1. August 2015

Gude,

danke für deine Anwort.

Zitat von X39

welche "bugs" willst du als anwender denn druch multithreading vermeiden (zudem ist mir neu das durch multithreading bugs vermieten werden :P)

was du mit mutex und semaphor in SQF kontext meinst ist mir jedoch nicht bekannt (wenn du daten in c/c++ aus arma lesen willst und somit SQF quasi umgehen ... good luck beim reverse engineering)

Nein, ich wollte nicht auf andere Sprachen zurückgreifen.
Bei den Bugs denke ich an kritische Abschnitte und ungewollte gegenseitige Beeinflussung. Wikipedia liefert dazu ein nettes Beispiel. Hier soll eine Zählvariable mitschreiben, wie oft ein bestimmter Programmeintritt stattfindet. Jetzt wird das Prog in zwei Threads recht zeitnah gestartet. Der Scheduler arbeitet wohl so, dass beie Threads jeweils abwechselnd eine Anweisung abarbeiten. Dadurch entsteht das Problem, dass Thread 1 den Zähler mit 0 einliest und Thread 2 daraufhin ebenfalls die 0 liest, sodass beide Threads den Zähler auf 1 setzen, obwohl zwei mal der Programmeintritt stattgefunden hat:

	Thread 1	Thread 2
1:	zaehler lesen
2:		zaehler lesen
3:	um 1 erhöhen
4:		um 1 erhöhen
5:	zaehler schreiben
6:		zaehler schreiben

Das fiese an solchen Bugs ist ja, dass sie nicht immer auftreten und sich das Verhalten von Schedulern nicht reproduzieren lässt. Vielleicht werden irgendwann auch mal zwei Anweisungen hinterinander ausgeführt oder ein Thread bekommt irgendwie eine höhere Prio.

Meine Frage zum Scheduler von ArmA war also, welches Verfahren dort angewand wird, um diese Nebenläufigkeiten umzusetzen. Wann finden Kontextwechsel statt, d.h wann darf welcher Thread rechnen? Kann man verbieten, dass ein Thread supendiert wird? (Klappt glaube ich sowieso nicht bei Multi CPUs).

Bin gespannt auf weitere Ideen/Antworten zu dem Thema!

X39 · 1. August 2015

dann vermeided multithreading noch immer keine bugs sondern führt zu welchen

nun ... der einzige weg für was du vor hast ist eine mutex implementation in SQF die wiederum das problem hat das der scheduler nach dem if(locked) erst mal pausieren könnte und somit den "lock" verhindert

also ist der einzige weg hier: extension schreiben die entweder t oder f zurück gibt

also:

Code

waitUntil{"mutex" callExtension "l1"};

z.b. (wobei das 'l' für lock stehen würde und die '1' für mutexSlot 1)
so würde man zumindest verhindern das man die schlechten scheduler timeouts mitnimmt

Hoegnison · 1. August 2015

Ich wusste doch, dass man hier fündig wird

Zitat von X39

dann vermeided multithreading noch immer keine bugs sondern führt zu welchen

Ich wüsste nicht wo ich das behauptet hätte. Ich habe gesagt, dass man in ArmA sicherlich einige Bugs vermeiden kann, die ungewollt durch die Nutzung von mehreren Threads auftreten

Sehe ich das also richtig, dass der Aufruf von Extensions atomar ist? Ansonsten bitte ich um weitere Erklärung

Gruß

X39 · 1. August 2015

Zitat von Hoegnison

Ich wusste doch, dass man hier fündig wird

Ich wüsste nicht wo ich das behauptet hätte. Ich habe gesagt, dass man in ArmA sicherlich einige Bugs vermeiden kann, die ungewollt durch die Nutzung von mehreren Threads auftreten

Sehe ich das also richtig, dass der Aufruf von Extensions atomar ist? Ansonsten bitte ich um weitere Erklärung

Gruß

Alles anzeigen

hab mich verlesen ...
bedingt durch die natur von programmiersprachen ist es nicht möglich ohne virtualisierung den aufruf eines codes zu unterbrechen (hierbei ist auch das einfügen von weiterem code damit der code unterbricht im begriff virtualisierung mit eingefasst) daher ist für SQF der aufruf von callExtension das selbe wie ein if befehl (als beispiel)
der unterschied ist, dass du in callExtension festlegst wie lange man "wartet"

callExtension kann jedoch nicht unterbrochen werden aufgrund der bereits erwähnten natur von C/C++ (und anderen maschinencode basierenden sprachen)

insofern:
ja, der aufruf ist atomar
gucken
vllt schuster ich gleich mal was zusammen das funktionieren sollte (extension)
*MÖP* *MÖP*
https://gist.github.com/X39/a3dfb1150687722a924d
nicht getestet sollte jedoch funktionieren

Spoiler anzeigen

PHP

#pragma once
#include <Windows.h>
#include <vector>
#include <mutex>
extern "C"
{
__declspec(dllexport) void __stdcall RVExtension(char *output, int outputSize, const char *function);
};
std::vector<std::mutex*> mutexList;
bool lockMutex(size_t index)
{
return mutexList[index]->try_lock();
}
bool unlockMutex(size_t index)
{
mutexList[index]->unlock();
return true;
}
bool toIndex(char c, size_t* out)
{
(*out) = c - '0';
return c < 10;
}
void __stdcall RVExtension(char *output, int outputSize, const char *function)
{
/*
* Function:
* c1 --> l | u
* c2 --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
*
* Returns:
* c1 --> t | f | e
* t ==> true
* f ==> false
* e ==> error
*/
if (outputSize == 0)
return;
if (function[0] == '\0' || function[1] == '\0')
{
output[0] = 'e';
output[1] = '\0';
}
switch (function[0])
{
case 'l':
size_t index;
if (!toIndex(function[1], &index))
{
output[0] = 'e';
output[1] = '\0';
}
else
{
output[0] = (lockMutex(index) ? 't' : 'f');
output[1] = '\0';
}
break;
case 'u':
size_t index;
if (!toIndex(function[1], &index))
{
output[0] = 'e';
output[1] = '\0';
}
else
{
output[0] = (unlockMutex(index) ? 't' : 'f');
output[1] = '\0';
}
break;
default:
output[0] = 'e';
output[1] = '\0';
break;
}
}
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
mutexList.resize(10);
for (int i = 0; i < mutexList.size(); i++)
{
mutexList[i] = new std::mutex();
}
break;
//case DLL_THREAD_ATTACH:
//case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
for (int i = 0; i < mutexList.size(); i++)
{
delete mutexList[i];
}
mutexList.clear();
break;
}
return TRUE;
}

Alles anzeigen

Hoegnison · 2. August 2015

Der edle Spender sei bedankt Ich werde demnächst mal reinschauen.

Dragon · 3. August 2015

Interessantes Thema, und ne coole Lösung (wenn sie denn funktioniert ^^).

Allerdings ist mir für sowas noch nie ein praktisches Beispiel in Arma untergekommen, und ich kann mir auch gerade keins ausdenken (im Rahmen von SQF; in der Engine selbst tritt sowas bestimmt häufiger auf). Für gewöhnlich schlag ich mich eher mit Synchronität bzw. Lokalität im MultiPlayer herrum. Soweit ich das überblicke wäre da die Lösung oben nicht wirklich hilfreich, oder?

Frage zu Multithreading in ArmA

Teilen

Tags