On Wed, 21 Sep 2005 20:11:42 +0200
"M.K." <kunibert@...> wrote:
> Also blieben noch die Spinlocks =FCbrig. Dann habe ich mich an die Schrei=
btasklets f=FCr die CMD-, B1- und B2-Daten an USB rangemacht. Diese haben u=
rspr=FCnglich so ziemlich gleich ausgesehen, wie die Lesetasklets heute noc=
h aussehen: Es gab eine Schleife, die nacheinander die Datens=E4tze aus der=
Queue geholt hat und dann ans USB gesendet hat.
Ich hoffe mal der sf-Mailman hat deine Mail nicht oben abgebissen.
Hab mich schon gewundert, warum du beim schreiben ausgerechnet Einzelbetrie=
b machst,
weil das geht massiv auf den Datendurchsatz.
> Da aber die Schreibfunktion des USB-Subsystem sofort zur=FCckkehrt, auch =
wenn der URB noch gar nicht =FCbertragen wurde, gab es Probleme, weil die S=
chleife sofort den n=E4chsten Datensatz senden wollte und das USB-Subsystem=
streikte.
Naja, da mu=DF dann eben der n=E4chste URB her. ;-) Gerade mal einem Blick =
auf die URB-API
geworfen. So lange Daten zum senden da sind, holt man einfach neue URBs mit=
usb_alloc_urb und=20
GPF_ATOMIC und schickt die ab. Der Completion-Handler ist immer der Gleiche=
und gibt die URBs
einfach immer nur frei (+ evtl. Fehlermeldung). Das Problem ist nur den =DC=
berblick dar=FCber zu
behalten, was gerade an URBs "unterwegs" ist, weil man mu=DF die ja zur=FCc=
kholen k=F6nnen, wenn der
Treiber entladen wird. Soll hei=DFen, man braucht noch ne Liste (siehe linu=
x/list.h) wo man die=20
Adressen der gerade verschickten URBs reinpackt, damit man die unlinken kan=
n.
> Also war der n=E4chste Gedanke, in der Schleife einen Spinlock einzubauen=
, der die Schreibfunktion des USB-Subsystems besch=FCtzt: Vor dem Aufruf wi=
rd der Spinlock besetzt. Kehrt die Funktion zur=FCck, bleibt die Schleife b=
eim n=E4chsten Durchlauf an dem Spinlock h=E4ngen, bis dieser vom Completio=
n Handler wieder freigegeben wird. Klingt doch logisch, oder?
Klar.
> Als ich das ausprobieren wollte, hab ich angefangen an meiner geistigen I=
ntegrit=E4t zu=20
zweifeln. Wie auch immer ich das angestellt habe, der Spinlock hat nichts b=
ewirkt.=20
Nach sehr vielen Tests hab ich dann gefunden, dass Spinlocks in Tasklets ke=
ine Wirkung haben!
Ist ja echt b=F6se! Das macht aber auch irgendwie Sinn, wenn ich so dr=FCbe=
r nachdenke...
> Obwohl der Spinlock 10 mal besetzt wird, l=E4uft das Tasklet durch, als o=
b es ihn
> nicht geben w=FCrde. Warum ist das so? Keine Ahnung!
M=F6gliche Erkl=E4rung: Das haben die Kernelentwickler einfach deaktiviert,=
weil, wozu noch
ein Spinlock im Tasklet, wenn beim Aufruf des Tasklets schon einer aktiv is=
t, damit
das Tasklet nur einmal l=E4uft wohl auch auf SMP-Systemen. Ein Problem sind=
die ganzen=20
Tasklet bla-aktiv-Variablen, die auch au=DFerhalb des Tasklets abgefragt we=
rden. Das
Problem ist, das die nicht atomar sind und es da b=F6se race condition-Fehl=
er geben kann.
z.B. Du checkst gerade au=DFerhalb des Tasklets die Variable mit if und der=
Wert ist 0
also l=E4uft nicht, nur hat die das gerade aktive Tasklets noch nicht auf 1=
gesetzt, weil
er eben erst gestartet wurde. Das du au=DFerhalb denkst, das das Tasklet ni=
cht l=E4uft,
gibts du zum Beispiel dem laufenden Tasklet den beschriebenen Speicher unte=
rm Arsch frei
und das Tasklet ist schreibt wild in der Landschaft rum. :-(
Ist eigentlich kien Problem das zu fixen (atomic_t benutzen), die Frage ist=
nur, ob ich
nicht wieder die H=E4lfte der Variablen =FCbersehe...
Gru=DF
Fabian
|