Semaphore

avrgcc ist ein Compiler und kein RTOS ...

Habe neulich eine Reportage gesehen: Kurz vor der Ägyptischen Küste
lassen sich einige Semaphoren finden :)

"avrgcc ist ein Compiler und kein RTOS ..."

Wer hat den bitte gesagt, dass man mit einem AVR kein Multithreading
machen kann??? Wie synchorinisert ihr dann eure Threads wenn nicht mit
Semaphore?

Und Kommentare wie "vielleicht im Mittelmehr" kann man sich sparen
...

Dann muss ich mir also meine atomare check+bitset Operation also selbst
zusammenbauen ...

Es hat keiner behauptet, dass das nicht geht. Nur ist der Compiler halt
nicht dafür verantwortlich. Du kannst entweder ein fertiges RTOS nehmen
oder programmierst dir eines selber.

Ich bin bisher immer gut ohne den Overhead einer Threadverwaltung
ausgekommen (auf dem MC), da ich die Programme einfach auf die
jeweilige Aufgabenstellung hin optimieren. Maximale Laufzeiten kann man
aus den Listings entnehmen (oder vielmehr berechnen).

Wenn du im Forum mal nach RTOS suchst, wirst du viele Infos finden.

Sich aufzuregen, wenn auf eine nicht besonders gut gestellte Frage wie
deine eine genauso schlaue Antwort kommt, finde ich nicht ok.

Um Thread synchronisieren zu können benötigt man atomare Operationen,
die der COMPILER zur Verfügung stellen muss.

Das hat nichts mit einem RTOS (Real-Time-Operating-System??) zu tun, da
sobald man Threading hat mit Real-Time eh nichts mehr los ist.

Semaphore kann man nicht nur bei Multithreading-Apps gebrauchen - stell
dir vor, du hast eine normale Applikation mit einem Timer-Interrupt und
beide verwenden eine bestimmte Resource eine Zeit lange z.B. ein LCD
(ist wohl nicht das beste Beispiel :-) dann musst du die Resource
Locken. Wenn du jetzt aber eine Abfrage drin hast wie
"Ist die Resource frei" und als nächsten Schritt
"Ja: dann locke sie" ist das ganze nicht Threading-Sicher, weil die
zwei Schritte vom Timer unterbrochen werden können. Dazu benötigt man
Semaphore - das sind Operationen, die genau die zwei Schritte atomar
ausführen, also nicht unterbrochen werden können.

Hmm - eigentlich müsste es sogar reichen, die Interrupts vor der
Abfrage zu sperren ...

Klar kann man es umständlicher machen, in dem man im Timer Flags setzt
und die Flags dann in der Hauptschleife des Hauptprogramms auswertet
und dann dort alles macht.

"Sich aufzuregen, wenn auf eine nicht besonders gut gestellte Frage
wie deine eine genauso schlaue Antwort kommt, finde ich nicht ok."

Wenn man die Grundkonzepte Threading + Synchronisation kennt, ist das
eine korrekt gestellte Frage - wenn man davon keine Ahnung hat, braucht
man auch keine Antwort zu posten.

Mfg
Thomas

Was ahben Semaphoren mit Echtzeitsystemen am Hut, ausser daß Sie
möglicherweise benutzt werden?

Atomare Zugriffe auf Compilerebene werden AFAIK durch den Typemodifier
'volatile' garantiert, hat aber rein gar nichts mit Semaphoren zu
tun.

Wenn ich da wirklich so falsch liege, dann bitte ich um Korrektur!

hmm - volatile sagt imho nur, dass eine z.B. Variable von der
Optimierung ausgenommen wird ...

Den Rest seh ich genauso :)

Jetzt aber wirklich... Die Semaphores haben nichts mit dem C Kompiler zu
tun. Wenn Du "Atomare" operationen brauchst (vermutlich
DB-Programmierer) dann soll deine Software die Interrupts vorlaeufig
ausschalten (sreg_copy=SREG; cli(); atomic_operation();
SREG=sreg_copy;).

+sei();

Und ja: ich wollte auf die Optimierung hinaus...

Aber wie gesagt, Semaphoren haben nichts mit dem Compiler zu tun.
Schau Dir gängige uC-OSe an, das ist doch alles schon vorgekaut...

OldBug: nix +sei(). Stell dir vor Du hast eine "Atomare" Routine.
Diese Routine ruft einen Trieber auf den Du vor 2 Jahren geschrieben
hast:

void atomare_routine(void) {
 cli();
 init_external_chip();
 tue_was_atomares();
 sei();
}

void init_external_chip(void) {
 cli();
 PORTB=0xff;
 sei();
}

Siehst Du den Bug? tue_was_atomares() ist nicht mehr atomar :) Mit
SREG=sreg_copy wird der I-bit nur dann wieder angemacht wenn er vor dem
cli() schon da war. Schliesslich ist sei() dasgleiche wie SREG |=
(1<<IBIT);

Regards,
Richard
Cape Town

Achja, sorry, Du sicherst ja das SREG...
Ich werd auch schon ganz dusselig im Kopf ;)

Nana, moment :-)

#define ENTER_CRITICAL_SECTION sreg_copy=SREG; cli();
#define EXIT_CRITICAL_SECTION SREG=sreg_copy;

void atomare_routine(void) {
 ENTER_CRITICAL_SECTION;
 init_external_chip();
 tue_was_atomares();
 EXIT_CRITICAL_SECTION;
}

void init_external_chip(void) {
 cli();
 PORTB=0xff;
 sei();
}

...dabei würde genau das Gleiche passieren: tue_was_atomares(); ist
nicht mehr atomar!

OldBug, ja genau, du sollst "habitually" durch SREG die interrupts
sichern, besonders in den "low-level" Routinen.

sei() ist nicht mehr moedisch :) Ban sei()!!!

In den Low-Level routinen verwende ich normalerweise GAR KEIN sei();,
höchstens vor dem Hauptprogramm, oder wenn sie im Hauptprogramm erst
Freigegeben werden sollen, dann erst da...

Eine Routine init_external_chip(), wie Du sie vorgestellt hast, sollte
man in der Tat nicht basteln ;)

Und Semaphoren haben im Compiler wirklich nix zu suchen, ist Sache des
Betriebssystems. Es mag ja sein dass manche Compiler Bibliotheken mit
den Schnittstellen zu Semaphoren mitliefern, diese sind dann aber
Betriebssystem spezifisch. Aber wo kein BS ist da hat der Kaiser (Hallo
Franz) sein Recht verloren <=|:-)

Stimmt ... nichtsdestoweniger kann man Semaphore nachbilden -
da der AVR kein OS hat, könnte es sein, dass AVRGCC ja in irgendeiner
Library Semaphore nachgebildet hat - wo wir bei der ursprünglichen
Frage wieder sind :-)

Ne Anmerkung:

Ich verwende immer cli(); + sei();, da ich mir die Sperre über eine
komplette Unterfunktion garnicht leisten kann.

Gerade bei CPUs mit nur einer Interruptpriorität müssen die Sperrzeiten
ja absolut kurz sein.

Ich sehe jetzt auch keinen Sinn darin, warum bereits der Aufruf einer
Funktion unter Sperre erfolgen sollte.

Sobald es sich außerdem um geringer wichtige Interrupts handelt,
disable ich auch nur diesen einen Interrupt, dann können die eiligen
Interrupts völlig unbehindert zuschlagen. In diesem Fall könnte auch
die Sperre nur dieses langsamen Interrupts über mehrere Unterfunktionen
hinweg tolerabel sein.

Ein cli(); ist quasi immer ein Tanz auf einer heißen Herdplatte, d.h.
ich versuche so schnell wie nur irgend möglich mit sei(); wieder kalten
Boden unter die Füße zu bekommen.


Die Frage einer durch Kaskadierung zu frühzeitigen Freigabe stellt sich
also für mich garnicht erst.


Peter

Die Antwort wurde schon lange gegeben:

"Du kannst entweder ein fertiges RTOS nehmen oder programmierst dir
eines selber."

Okay - dann hat also AVRGCC keine nachgebildeten Semaphoren wenn ich
deine Antwort verstanden habe.

Mehr wollte ich ja garnicht wissen :-)

Wieso denn nicht gleich so?

** IDENTITÄTSDIEBSTAHL **

Auch dieser Beitrag ist nicht von mir:

  Autor: Rufus T. Firefly
  Datum: 12.04.2005 09:53

  vielleicht im Mittelmehr?


Wer mich kennt und/oder schon Beiträge von mir gelesen hat, wird
wissen, daß ich in der Lage bin, so einen kurzen Satz korrekt zu
formulieren. Auch neige ich nicht dazu, zu sinnvollen Fragen völlig
schwachsinnige Antworten zu geben; das machen andere Leute, die
offensichtlich sogar zu feige sind, ihr anonymes Pseudonym zu
verwenden.

Es wird Zeit dafür, daß sich die entsprechenden Idioten aus diesem
Forum zurückziehen.
Eine Anmeldepflicht wäre diesbezüglich wohl auch förderlich.

@Thomas:
Kannst Du uns einen C-Compiler nennen, bei dem Semaphoren zum
Sprachumfang gehören? Auch mir ist die Zugehörigkeit von Semaphoren zu
einem RTOS-Kern die geläufige Lesart; selbst die Reduktion von
Semaphoren auf eine atomare Operation (i.d.R. ein entsprechende
Maschinenbefehl) kenne ich nur als Bestandteil eines RTOS-Kerns.

Hmm - Posix-Semaphore, die es z.B. unter Linux + Unix gibt ... ich
müsste aber nachschauen was man da includen muss ...

Die gehören aber tatsächlich zum Betriebssystem dazu ... allerdings
muss es nicht unbedingt ein RTOS sein - ich wollte nur wissen ob AVRGCC
vielleicht sowas schon drin hat, weil man synchronisations-Mechanismen
wie Semaphore eigentlich häufig brauchen kann ...

Hätte ja sein können :-)

Nochwas: Zum Sprachumfang natürlich nicht - aber genauswenig gehört doch
die STL zum Sprachumfang von C++ ...

<ot>
> Eine Anmeldepflicht wäre diesbezüglich wohl auch förderlich.

Die Möglichkeit einer Anmeldung wäre schon sehr vorteilhaft, denke ich.
Aber eine Anmeldepflicht finde ich nicht so gut; Identitätsdiebstahl ist
bereits durch freiwillige Registrierung verhindert.
Gerade Gäste posten aber gerne mal Antworten oder Fragen, ohne sich
gleich registrieren zu wollen. Bei einer Anmeldepflicht würde das Forum
einige User, nicht nur störende, verlieren, fürchte ich.
</ot>

> aber genauswenig gehört doch die STL zum Sprachumfang von C++ ...

Doch, guck mal in den C++-ISO-Standard.

Hi

es gibt durchaus Sprachen bei denen Semaphoren Bestandteil der Sprache
selbst sind. Eine solche ist z.B. Pearl.

Matthias

@Matthias:
Pearl ist aber, wenn ich mich recht erinnere, eine Sprache, die
RTOS-Elemente mit sich bringt.

Vor längerem (müsste noch in den 80ern gewesen sein) gab's mal in der
c't eine Artikelreihe dazu.

Ansonsten:
http://www.irt.uni-hannover.de/pearl/pearl-gb.html


@Chris:

Magst Du das mit der freiwilligen Registrierung noch ein wenig
elaborieren?

Hi

schreib ich doch. Werner B. schreibt das Semaphoren ins Betriebssystem
gehören. Das stimmt so nicht. Es gibt eben Sprachen, und Pearl ist eine
davon, die diesen Mechanismus auf Sprachebene mitbringen. Die Sprache
muß das also per Definition können. Also ist die Semaphore Bestandteil
der Sprache und nicht des OS. Man könnte auch sagen das das OS Teil der
Sprache ist.

Matthias

PEARL wurde extra dafür entwickelt, C nicht!

@Matthias:

>>> Man könnte auch sagen das das OS Teil der Sprache ist.

Nein!

Gruß, Michael

> Man könnte auch sagen das das OS Teil der Sprache ist.

Du sprichst indirekt den vielleicht wichtigsten Unterschied an, der C
von anderen Sprachen hervorhebt.

C wurde offiziell von ANSI standardisiert.

Somit gibt es feststehende Regeln, ab wann sich ein Programm guten
Gewissens als "ANSI-C-Compiler" bezeichnen lässt. Viele anderen
Sprachen dagegen, auch etwa Java, sind nicht offiziell standardisiert.
Der "Standard" ist bei solchen Sprachen meistens der
Compiler/Interpreter des Herstellers; die Sprache kann sich also mit
jeder neuen Compiler-Version ändern.

Dass C standardisiert ist, hat einige Vorteile. Man kann zum Beispiel
sicher sein, dass sich jeder sog. "well-formed" ANSI-C-Code auf jedem
ANSI-C-Compiler kompilieren lässt.
Ein Nachteil ist natürlich, was man in diesem Thread wieder mal
besonders gesehen hat: Standard-C bietet keine betriebssystem- oder
hardware-spezifischen Funktionen an.
Es wäre zwar unter Umständen möglich, Threads (und damit Semaphoren) in
den C-Standard zu setzen, trotzdem hat sich das Standardisierungskomitee
dagegen entschieden. Der Grund war, soweit ich weiß, dass solche
Funktionen einen enormen Implementierungsaufwand bedeuten würden.
Wären Threads oder ähnliches in den C-Standard aufgenommen worden,
würde es mit Sicherheit nicht für so viele verschiedene Architekturen
ANSI-C-Compiler geben.


<ot>
> Magst Du das mit der freiwilligen Registrierung noch ein wenig
> elaborieren?

Ich dachte an sowas, was etwa auf www.c-plusplus.de recht erfolgreich
praktiziert wird.

Dort kann jeder posten, ob man registriert ist oder nicht. Viele Fragen
werden dabei von Unregistrierten gestellt, aber auch viele Antworten. In
den Nicht-OT-Foren sind Antworten von Unregistrierten seltener als in
OT, aber trotzdem vorhanden. Es gibt auf dem Forum sogar "prominente"
Unregistrierte, die regelmäßig im Forum unterwegs sind und hilfreiche
Antworten geben, sich aber (aus welchen Gründen auch immer) nicht
registrieren.
Nur in einem Unter-Forum, der Spiele/Grafikprogrammierung, sind
Postings von Unregistrierten nicht mehr zugelassen. Das ist schade, war
aber notwendig, da dieses Forum blöde Fragen und blöde Antworten
regelrecht anzieht. Wenn mehrmals pro Tag die Frage kommt, wo man
Tutorials für einem Quake-like Ego-Shooter findet, besteht die Gefahr,
dass ein Forum sein Niveau verliert.

In allen anderen C++-Unter-Foren dürfen unregistrierte User problemlos
posten. Ich denke, ohne die Möglichkeit des unregistrierten Postings
würde das C++-Forum sehr viele User verlieren und die Hemmschwelle für
Neueinsteiger erhöhen.

Ich weiß nicht, wie viele Moderatoren und/oder Admins dieses Forum hat.

Das C++-Forum besitzt jedenfalls trotz der Möglichkeit des
unregistrierten Postens ein nicht niedriges Niveau, da die Moderatoren
Präsenz zeigen. Dadurch wissen die meisten, dass ihre Postings, sollten
sie beleidigend oder störend sein, ziemlich schnell den Weg alles
Irdischen gehen.
In diesem Forum wird es sehr verdeckt gehalten, wer die Möglichkeit
besitzt Postings zu löschen (nur Andreas?). Aber auch hier sieht man
ja, dass das Niveau ziemlich gut ist, obwohl man unregistriert posten
darf.

Eine Registrierung hätte natürlich auch noch andere als den
Identitätsschutz: Man könnte seine Beiträge nachträglich editieren, man
könnte (je nach Software) E-Mail-Benachrichtigungen bei neuen Beiträgen
erhalten, man könnte E-Mails von anderen Usern empfangen, ohne seine
E-Mail-Adresse zu posten.


Was aber wirklich nervig sein kann, sind hunderte blinkende Features
irgendeiner neuen Forensoftware. IMHO wäre z.B. in so einem Forum wie
hier etwa ein Avatar völlig fehl am Platze; es sollte schließlich der
Stil eines "technischen Forums" gewahrt bleiben, den es zur Zeit ohne
Frage besitzt.

Aber ich denke, hier besteht erstmal keine Gefahr, dass überstürzt und
unüberlegt eine neue Forensoftware installiert wird.
</ot>

Ah, danke für die Aufklärung. Ich hatte Dich zunächst missverstanden und
angenommen, Du beschriebest ein Feature dieses Forums hier, das ich
vollkommen übersehen hatte.

D'accord; ein Mischbetrieb aus freiem Forum und Anmeldemöglichkeit
wäre in der Tat eine sehr praktische Lösung. Auch Deine Abneigung den
übliche Forenfeatures gegenüber teile ich. "Avatare" und vor allem
diese beknackten Smiley-Graphiken sind an Entbehrlichkeit nur schwer zu
überbieten.
Lasset uns hoffen ...

doch das geht... z.b java "uhr" die mit so komischen buchstaben
aufgebaut ist und dem mauszeiger folgt... das ist noch sinnfreier als
avatare ;) am avatar kann man wenigstens den geisteszustand des
jeweiligen besitzers ablesen... und bei den smilies hat man zum grübeln
wem soo fad war das zu zeichnen.. sprich die uhr ist das sinnfreiste ;)

73

OK, Hans, dieser Java-Scheissdreck "toppt" diese bescheuerten Smileys
noch.

Die graphische Darstellung dieses Forums sollte ziemlich exakt genau so
bleiben, wie sie ist; dafür übrigens ein Lob an Andreas!

btw, dabei handelt es sich um JavaScript (vorausgesetzt wir reden vom
selben unnützen Quatsch).

Ich bin kein Java-Programmierer, aber soweit ich weiß wären solche noch
penibler, was die Unterscheidung Java<->JavaScript angeht. ;-)

> Die graphische Darstellung dieses Forums sollte ziemlich exakt
> genau so bleiben, wie sie ist; dafür übrigens ein Lob an Andreas!
Jep, der Stil vermittelt einen "technischen" Eindruck und passt damit
ziemlich gut zum Thema.
Wobei ich mir ein kleines Feature schon gerne wünschen würde: Maximal n
Postings pro Seite, der Rest des Threads liegt auf weitere Seiten
verteilt. Dann würden Monsterthreads mit >300 Beiträgen den Browser
nicht so stark ausbremsen.

Zurück zum Thema: auch ich kenne Semaphore nur als Betriebssystem
Bestandteil und denoch stimmt gleichermaßen das Argument in Bezug auf
die Fähigkeiten des Compilers. Möchte man ohne Tricks mit einem
Compiler Semaphore programmieren so muß die Hardware und auch der
Compiler ganz bestimmte atomare Operationen unterstützen, ohne gehts
nicht. Atomare Operationen sind unabdingbar dafür.Auch eine Kombimation
aus PUSHF + CLI() + Operation + RETI ist da wenig hilfreich, denn sie
sind nicht atomar und funktionieren nur auf einer MCU wie dem AVR mit
IRQ's ohne Prioritäten.

Gruß Hagen

Hi

solange das OS (bzw. die Laufzeitumgebung) einen Prozesswechsel sicher
verhindern kann (z.B. durch sperren aller Interrupts) braucht der
Controller keinerlei spezielle Operationen beherschen. Allerdings will
man daß abschalten von INT's vermeiden. Deshalb haben viele
Prozessoren eben atomare Operationen um die Funktion von Semaphoren
auch ohne das abschalten der INT's zu realisieren.

Matthias

> Deshalb haben viele Prozessoren eben atomare Operationen um die
> Funktion von Semaphoren auch ohne das abschalten der INT's
> zu realisieren.

Wenn Du damit Operationen wie test-and-set oder lock-exchange meinst,
dann sind die bei reinen Microcontrollern eher selten. Allenfalls als
netter Nebeneffekt von to-memory Operationen bei CISC ISAs.

Der Grund ist ja auch ein anderer: Interrupts abzuschalten verhindert
Konflikte bei Interrupt-Routinen und parallelen Threads. Ohne weitere
Massnahmen bleiben es jedoch mehrere Buszugriffe und es hilft folglich
nicht bei parallelen Prozessoren oder bei I/O-Controllern mit
Eigenintelligenz.

Wenn also spezielle Befehle existieren, dann um das Problem auf der
Ebene der Bustransfers anzugehen.