<future> nötig oder nicht

MegaV0lt · December 6, 2024 at 10:11 AM

Ich habe im Code von Skin flatPlus mehrere Stellen , wo Timer abgefragt werden. Beispiel:

Code

            if (Config.MenuTimerShowCount) {
                uint TimerCount {0}, TimerActiveCount {0};
                LOCK_TIMERS_READ;  // Creates local const cTimers *Timers
                for (const cTimer *Timer = Timers->First(); Timer; Timer = Timers->Next(Timer)) {
                    ++TimerCount;
                    if (Timer->HasFlags(tfActive))
                        ++TimerActiveCount;
                }  // for
                m_LastTimerCount = TimerCount;
                m_LastTimerActiveCount = TimerActiveCount;
                NewTitle = cString::sprintf("%s (%d/%d)", Title, TimerActiveCount, TimerCount);
            }  // Config.MenuTimerShowCount

Display More

Aber ein mal auch das:

Code

            // Look for timers
            auto recCounterFuture = std::async([&NumRec]() {
                LOCK_TIMERS_READ;  // Creates local const cTimers *Timers
                for (const cTimer *ti = Timers->First(); ti; ti = Timers->Next(ti)) {
                    if (ti->HasFlags(tfRecording))
                        ++NumRec;
                }
            });
            recCounterFuture.get();
            if (NumRec) {

Bracht man das async zeugs? Ich verstehe den Nutzen in dem Fall nicht.

wirbel · December 6, 2024 at 5:13 PM

Jemand hat wohl damit versucht zu erreichen, in der Variable NumRec die Anzahl aktiver Timer mit weiteren Threads zu ermitteln, und zwar so, dass die Anzahl in der Variable steht, noch bevor der restliche Code aufgerufen wird.

Sobald die Lambda Funktion durchgelaufen ist, wird im Rückgabe std::future ein Flag gesetzt. get() wartet dann solange im aktuellen thread bis das Ergebnis da ist.

Geht wohl um Geschwindigkeit..

kfb77 · December 6, 2024 at 5:19 PM

Aber mit gleich danach den get() call, bringt doch keinen Geschwindigkeitsvorteil.

Vielleicht wollte man damit einen invalid lock sequence vermeiden, indem man den Lock in einen eigenen Thread gepackt hat ?

MegaV0lt · December 6, 2024 at 5:32 PM

So weit ich das als Laie sehe, ist die baserender.c nicht in einem eigenen Threat und es ist auch die einzige Stelle im Code.

Vielleicht wollte man damals so was einbauen, hat aber nicht weiter gemacht? Ich kann das sicher deaktivieren, oder?

https://github.com/MegaV0lt/vdr-p…serender.c#L447

wirbel · December 6, 2024 at 6:14 PM

Es ist eine synchronisation zwischen mehreren threads, ob das auch nützlich ist, kann man nur verstehen wenn man im Code gräbt.

MegaV0lt · January 27, 2025 at 4:54 PM

Quote from kfb77

Vielleicht wollte man damit einen invalid lock sequence vermeiden, indem man den Lock in einen eigenen Thread gepackt hat ?

Ich denke das ist es.

MarkusE · January 27, 2025 at 5:44 PM

> Vielleicht wollte man damit einen invalid lock sequence vermeiden, indem man den Lock in einen eigenen Thread gepackt hat ?

Und dann noch auf den anderen Thread warten ...-> deadlock, der aber keine invalid lock sequence auslöst. "Denn sie wissen nicht, was sie tun".

kfb77 · January 27, 2025 at 6:01 PM

Hast natürlich Recht, macht so keinen Sinn. Besser wäre es die Lock Reihenfolge zu korrigieren.

Aber solange im aufrufenden Thread kein LOCK_TIMERS_WRITE drin ist, wird der LOCK_TIMERS_READ immer irgendwann erfolgreich sein.

MegaV0lt · January 27, 2025 at 6:38 PM

Da ist guter Rat teuer. Das mit dem async ist also nicht die beste Idee...

Das in den Flush() zu verschieben würde das überhaupt was ändern?

TopBarUpdate() wird ja in Flush https://github.com/MegaV0lt/vdr-p…laymenu.c#L3520 aufgerufen

Code

void cFlatDisplayMenu::Flush() {
    if (!MenuPixmap) return;
    TopBarUpdate();
...

Und in TopBarUpdate() https://github.com/MegaV0lt/vdr-p…serender.c#L307 ist die Abfrage drin:

Code

        if (Config.TopBarRecordingShow) {
            auto RecCounterFuture = std::async(std::launch::async, [&NumRec]() {
                LOCK_TIMERS_READ;  // Creates local const cTimers *Timers
                for (const cTimer *Timer = Timers->First(); Timer; Timer = Timers->Next(Timer)) {
                    if (Timer->HasFlags(tfRecording))
                        ++NumRec;
                }
            });
            RecCounterFuture.get();
...

Edit: Wäre schön, wenn man die Werte auch einfacher vom VDR bekommen könnte (z.B. TimerRecording, TimerActive, Timers)

<future> nötig oder nicht

Participate now!

Users Viewing This Thread