Mutex in C



  • Hallo,

    ich würde gerne diese Methode (Hier nur ein Ausschnitt) mit einem Mutex umschliesen.

    Da ich nicht der große C Programmierer bin hoffe ich Ihr könt mir dabei helfen.

    00798 int avcodec_open(AVCodecContext *avctx, AVCodec *codec)
    00799 {
    00800     int ret= -1;
    00801 
    00802     entangled_thread_counter++;
    00803     if(entangled_thread_counter != 1){
    00804         av_log(avctx, AV_LOG_ERROR, "insufficient thread locking around avcodec_open/close()\n");
    00805         goto end;
    00806     }
    00807 .....
    

    Wo setz ich an und wie funzt das genau.

    In Java setz ich im einfachsten falle ein synchronized vor den Methodennamen.

    Ich hab gelesen das in C Mutex ein Attribute Objekt hat das ich initialisieren muss.
    Wieso überhaupt ein Object? C ist doch garkeine OO Sprache.

    gruß



  • Falsches Forum? WinAPI...? 😕



  • Ähh. ?????

    Ich würd sagen genau das richtige.



  • subsonnic schrieb:

    Ähh. ?????

    Ich würd sagen genau das richtige.

    ANSI-C kennt sowas wie Threads nicht und braucht auch keine Mutexe oder Critical Sections.



  • Das ist nicht ganz richtig.

    Zwar kennt standart C keine threads und demnach auch keine Mutexe, aber implementiert wurden Mutext trotzdem später.

    Mein Javaprogramm ruft über fobs4jmf ffmpeg auf.

    ffmpeg arbeitet mit avcodecs.

    Diese Methode die ich aufgezeigt habe, ist nicht threadsicher wie man sieht.

    Da ich in java aber mit threads arbeite muss ich dort an der stelle in avcodec.h synchronisieren.

    Haab auch schon ein synchronized im java code eingecodet aber das zeigt leider nur einen teilerfolg.

    Jetzt wollte ich eben mal direkt an den Methoden die threadunsicher sind anfassen.



  • So per se sieht man der Funktion nicht an, das sie nicht thread-safe ist. Normalerweise werden Funktionen nicht synchronisiert, sondern nur der Zugriff auf Daten. Z.B. bei "entangled_thread_counter++" koennte es Probleme geben, da die Variable global definiert ist. Nun fragt sich, warum diese noetig ist, etc ...

    Zu Threads und Co kann ich dir nur pthreads empfehlen. Zu dieser Bibliothek gibt es auchgenug Tutorials im Netzt. Sie ist auch fuer Windows verfuegbar.



  • knivil schrieb:

    Z.B. bei "entangled_thread_counter++" koennte es Probleme geben, da die Variable global definiert ist. Nun fragt sich, warum diese noetig ist

    Die Variable dient offensichtlich dazu, einen Fehler auszulösen in dem Fall, dass Programmierer die Dokumentation missachten und thread-unsichere Funktionen aus mehreren Threads gleichzeitig aufrufen 😃

    Die wirklich problematischen Dinge werden dann weiter unten in der Funktion kommen.

    @subsonnic: Verwendest du denn weitere Threads in deinem Java-Programm, um ganz andere Dinge zu tun, oder rufst du wirklich die unsicheren Funktionen parallel auf, z.B. um mehrere Dateien gleichzeitig zu dekodieren?

    Wenn letzteres der Fall ist, solltest du einfach einen einzelnen globalen Mutex mit einer Thread-API deiner Wahl (z.B. pthreads) anlegen, und den immer locken, wenn du eine von den problematischen Funktionen aufrufst. Letztendlich sind es ja nur ein paar Inititalisierungsfunktionen, das restliche Kodieren/Dekodieren ist ja thread-safe.

    Edit: also irgendwo

    static pthread_mutex_t ffmpeg_mutex = PTHREAD_MUTEX_INITIALIZER;
    

    und dann dann, wenn du so eine Funktion aufrufst,

    pthread_mutex_lock(&ffmpeg_mutex);
    retval = avcodec_open(avctx, codec);
    pthread_mutex_unlock(&ffmpeg_mutex);
    


  • knivil schrieb:

    Zu Threads und Co kann ich dir nur pthreads empfehlen. Zu dieser Bibliothek gibt es auchgenug Tutorials im Netzt. Sie ist auch fuer Windows verfuegbar.

    brauchste aber nicht für windows. unter win deckt die winapi alles ab, wahrscheinlich noch mehr, als mit pthreads möglich ist.
    🙂



  • Wieso wird der OP denn gleich bezichtigt, Windows zu benutzen? :p

    Offenbar geht es ja um ein Java-Programm, das FFmpeg verwenden soll. Da muss man ja keine unnötigen Portabilitätsprobleme schaffen, indem man die Windows-API verwendet.

    Wenn zusätzlich ohnehin irgendein Framework verwendet wird, das Mutexe anbietet (glib, sdl, ...) kann man natürlich gleich die nehmen, ansonsten dürfte pthreads eine gute Wahl sein.



  • Ja Danke erstma für die vielen Antworten.

    Mein Arbeitgeber hat es sich grad anders überlegt. Er will andere Alternativen für ein effizientes Konvertieren von Videos ausprobieren.

    Aus diesem Grund kann ich mich leider nicht weiter mit dem Problem beschäftigen.
    Zeit ist Geld.

    Schade.

    Aber etwas Wissen konnte ich mir mit eurer Hilfe ja schon aneignen.



  • brauchste aber nicht für windows. unter win deckt die winapi alles ab, wahrscheinlich noch mehr, als mit pthreads möglich ist.

    Die WinAPI finde ich aber kacke von der Benutzung her ...


Log in to reply