Threadsafety in OB's

Chefmech

Level-1
Beiträge
267
Reaktionspunkte
26
Zuviel Werbung?
-> Hier kostenlos registrieren
Mahlzeit

Ich verwende 2 OB's für mein Programm, OB61 für die heiklen sachen, OB1 für den Rest.
Leider ist das ganze nicht zu 100% Threadsafe programmiert, was natürlich alle paar Tage mal ein Problem aufwirft...

--> Gibts es die Möglichkeit, einzelne Programmabschnitte (Funktionen) atomar, also nicht unterbrechbar zu machen?
 
Also ich verstehe die Frage überhaupt nicht. Was für ein "Problem" entsteht denn alle paar Tage? Und was meinst du mit atomar bzw. nicht unterbrechbar?
 
Hallo,
ich verstehe die Anfrage so, dass die beiden Abläufe direkt nichts miteinander zu tun haben, jedoch auf die gleiche Perepherie (hier vor Allem schreibend) zugreifen. Da würde es dann passieren können, dass der eine Ablauf den Ausgang x abschaltet (was auch notwendig wäre) un der andere Ablauf ihn wieder einschaltet (weil es ihm gerade genehm wäre). Ist das so ?
In dem Fall (so ganz pauschal) hättest du dein Programm selbst nicht Threadsicher erstellt und da würde ich ansetzen. Der Sinn der anderen OB's (neben dem OB1) ist es ja gerade, im Ereignisfall sofort anzuspringen (wie ein Interrupt).

Aber vielleicht schreibst du ja noch etwas mehr dazu ...

Gruß
Larry
 
Du kannst mit den entsprechenden Systemfunktionen Interrupts sperren und wieder freigeben (SFC 39, SFC 40).
Aber wo tritt das Problem denn auf? Alle Zugriffe auf <= 4 Byte sind atomar. Für alles was größer ist kann man UBLKMOV anstelle BLKMOV verwenden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe 2 Programmteile (OB1 und OB61), die Kommunikation läuft eigentlich im OB1.
Nun verwenden aber beide OB's den selben Sendepuffer, da die Kommunikation im OB1 läuft, der OB61 aber auch Telegramme absetzen kann.

--> Wenn jetzt die Funktion "WriteToSndBuf" im OB1 auf der falschen Zeile Unterbrochen wird und der OB61 dann die selbe Funktion aufruft, verhaut's mir den Sendepuffer.
Ich müsste also die Funktion "WriteToSndBuf" ununterbrechbar machen, dann wär das Problem gelöst, ansonsten müsst ich da ziemlich aufwändig zusätzliche Kommunikationsmechanismen zwischen den beiden OB's aufbauen.
 
Obwohl es (glaube ich) so in etwa ist, wie ich es angenommen habe ist es nicht so, dass ich deinen Ansatz wirklich verstehe.
Warum muß der OB61 also auch senden ? Er könnte doch genauso auch einen Merker setzen (oder so), der dann das zyklische Programm veranlaßt, wenn es paßt zu senden, was zu senden ist ...

Gruß
Larry
 
Das wär natürlich der richtige Ansatz, das ganze so zu entkoppeln.
Ein einzelner Merker reicht da nicht, das sind unterschiedliche Anzahl und Typen von Telgrammen, da muss ich mir dann ziemlich aufwändig einen Zwischenpuffer aufbauen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Denke das wirst du aber leider nicht großartig umgehen können, alternativ wären komplett getrennte Funktionen fürs Senden mit getrennten Puffern. Wobei du beachten solltest, dass die Kommunikationsbausteine teilweise ja auch asynchron zum OB1 rennen, dafür gibts ja dann die Statusflags.
 
Das wär natürlich der richtige Ansatz, das ganze so zu entkoppeln.
Ein einzelner Merker reicht da nicht, das sind unterschiedliche Anzahl und Typen von Telgrammen, da muss ich mir dann ziemlich aufwändig einen Zwischenpuffer aufbauen.

Das wäre nicht der richtige sondern m.E. der einzige Ansatz, das sauber und fehlerfrei hinzubekommen. Denk vielleicht noch einmal drüber nach ... 8)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ohne deine Funktion WriteToSndBuf zu kennen, denke ich, dass es möglich sein sollte, eine Variante zu erstellen, die anstelle des eigentlichen Sendepuffers einen anderen Speicherbereich (DB) beschreibt.

Im OB61 diese modifizierte Variante aufrufen.

Im OB1 dann von dem Zwischenspeicher in den eigentlichen Sendepuffer kopieren.

Falls der OB61 in schnellerer Folge Telegramme erzeugt, als OB1 oder der Sendemechanismus auf Systemebene diese "wegschaffen" kann, muß der Zwischenspeicher ein FIFO sein.
Falls nicht, reicht ein Merker für belegt/frei.
 
Zurück
Oben