| Re: Synchronisierung Kategorie: Programmierung (von André H. - 30.10.2005 18:00) | ||
| Als Antwort auf Synchronisierung von Christian Jost - 26.10.2005 10:37 | ||
| ||
|
Hallo Chris, > 1) > Ich habe 4 Worker-Threads. Sobald einer fertig ist, soll dieser ein globales Flag setzen: > > int ready; > ... > ready = TRUE; > > Ein anderer Thread führt folgendes aus: > > loop > { > wait ready; > ready = FALSE; > ... > } > > Kann die virtuelle Maschine durcheinander geraten (=Absturz), wenn zwei Threads "gleichzeitig" > versuchen auf dieselbe Variable zuzugreifen? Es spielt keine rolle ob das Flag mehrmals gesetzt > wird oder von wem es gesetzt wird. Es ist einfach wichtig dass es gesetzt wird. > Ich möchte für diesen Fall kein capture/release benutzen um die Programmausführung nicht durch > Wartezustände zu verlangsamen. Sobald auch nur ein zweiter Thread schreiben auf die Variable zugreifen, mu� dies gecaptured werden. Ansonsten läuft Dein Programm nicht, wie erwartet. Denn, so wie ich es sehe, willst Du mit in einem Thread warten bis einer der anderen an einem bestimmten Punkt angelangt ist. Der wartende Thread soll aber nur einmal etwas durchlaufen, auch wenn etwas später der ein weiterer Thread fertig ist. Dies geht eigentlich ganz einfach: Verwende ein explizites Capture plus eine weitere Statusvariable. byte flag, status; thread x bis y { //... capture flag; if status==0 ready=TRUE; release; //... } thread xyz { //... while // erweitertes wait { capture flag; if ready==TRUE { ready=False; Status=1; release; break; } release; yield; } //... } > 2) > wenn ich durch run 255 die Priorität erhöhe, so wirkt sich das sofort aus oder erst > nach dem nächsten Thread-Wechsel? > Ich denke da an folgende Anwendung für einen Ringbuffer: > > run 255; > capture sema; > bufCount = (bufCount + 1); > release; > resume; > > Ziel ist auch hier wieder möglichst wenig zu blockieren. Du kannst natürlich auch mit den Threadprioritäten spielen. Diese änderung wirkt sich unmittelbar aus, und nicht erst nach einem Threadwechsel. Das wären dann die von mir sog. Pseudo-Captures. Allerdings sollte man vorher immer mit yield; kurz die Rechenzeit abgeben, damit man nicht später einmal nach einem Fehler sucht, falls ein Thread einmal doch standardmä�ig mit einer höheren Prio läuft und die Prio für den aktuellen Durchlauf nicht hoch genug ist, damit es keinen Threadwechsel im falschen Moment gibt. Bedenke, da� die Zeile ready=False; bereits 2 Instruktionen sind und bufCount = (bufCount + 1); bereits 4. Wenn Du mit den Pseudo-Capturen arbeitest und kein yield benutzt, mu�t Du immer die Instruktionen mitzählen, um zu sehen, ob noch genug Luft ist. Dabei sind die zur Verfügungstehenden Instruktionen 255 - der nor,mal gewählten Prio des Threads. Im obigen Bsp. von Dir könntest du das (normle) Capture komplett weglassen, wenn der Thread sonst mit einer Prio kleinergleich 250 läuft. > 3) > In diesem Eintrag: 11080 > hat André H. geschrieben, dass andere Threads immer lesend auf Variablen zugreifen dürfen > (ohne capture) wenn sie nur von einem Thread verändert werden. > Gilt das auch für long, float und string oder nur für byte/int? Der Variabeltyp ist dabei völlig egal. Allerdings gibt es bei Strings eine kleine Besonderheit, da der Compiler Anweisungen etwas unterschiedlich kompiliert. Daher kann es im ungünstigsten Fall einmal vorkommen, da� der String einmal leer ist, obwohl er es nicht sein sollte. Das hängt damit zusammen, wie der Compiler mit z.B. s=s+t; im Vergleich zu str.putstring(s,t); umgeht. Ich verwende zugegebenerma�en auch gerne die erste Schreibweise, jedoch ist die zweite optimaler, obwohl das Ergebnis gleich aussieht. In der Ersten Variante wird der String zuvor gelöscht und noch ein paar andere Anweisungen ausgeführt, soda� der einfache (String-)Terminus auf über 8 Instruktionen kommt, der zweite aber nur auf 3. MfG André H. Antworten bitte nur ins Forum! Fragen per EMail auf Forum-Postings werden nicht beantwortet! Das macht meine Heizung gerade | ||
Antwort schreiben Antworten: | ||