allgemein synchroniszed verständnisfrage

[Guest]

hi synchronised (obejct) { blah blah und nochmehr blah text }

macht doch nen lock auf des object.

wenn wir uns nun irgendwo in der blahblah stelle befinden, und ein anderer thread oder irgend ein idoit der genau in dem moment auf das applet klickt, wird dann hinten eingereiht in die queue?

also die ieg frage.

wenn ein object gelocked wird via synchro kann ein anderer thread etc der auch auf das object zugreifen will nicht zugreifen sondern muss chillen?


merci für die hilfe

 

[SlaterB]

muss warten ja, gibt aber keine Queue, wer als nächster dran kommt entscheidet sich per Zufall

 

[Guest]

ah und folgendes, sagen wir es gibt:

eine instanz von nem applet und einen thread und einen coolen benutzer der rumklickt.
wenn der thread gerade snycro auf das applet macht und hier halt was krass dickes berechnet was n paar 100 ms braucht und jetzt kommt der nichtsanehnde benutzer daher und klickt z.B auf ein label,button,canvas, irgend so n schnickschnack halt.


wird das dann überhaupt vom applet wargenommen? also sagen wir mal an dem schnickschnack object ist ein mouselsitener oder irgend n anderer eventlistener registriert.

geht der klick verloren oder wir der von irgend ner höheren macht aufgefangen und dem applet erst übergeben wenn es unlocked ist?

bevor ich hier was sinnloses programmier zuerstmal anchfragen.

vielen vielen dank für die hilfe

 

[Wildcard]

Wir alle hier würden sehr begrüßen, wenn du dich deutlich ausdrücken und vom Schreibstil eines 12 Jährigen entfernen würdest.
Lang laufende Aktionen müssen grundsätzlich in einem seperaten Thread ablaufen, damit der Dispatch Thread nicht blockiert wird. Weitere Fragen konnte ich aus diesem Erguss nicht extrahieren.

 

[Guest]

Sehr geehrte Damen und Herren,

ich würde Sie bitten mit ihren fundierten Fachkenntnissen mir bei folgender Problematik behilflich zu sein.

ich arbeite mit den folgenden Komponenten

- eine Instanz einer Klasse die von der Klasse Applet erbt
- eine Instanz eines Threads welcher mit folgendem Befehl auf die Instanz der Applet-Klasse zugreift

synchronized( myApplet){

myApplet.modifiziereVariablen();

}

- Eine Instanz einer Human Resource welche durch Betätigung der linken Maustaste auf, einer in der Tochterklasse der Basisklasse Applet ,gelegten Panel zugreift. Dieses Panel verfügt über einen MouseListener der daran registriert wurde.




Der freundliche Betrachter dieses Artikel der gleichzeitig ein potenzielle Träger der Lösung für das folgende Problem ist,sollte sich nun folgendes Szenario vorstellen.

In dem seperaten Thread wird, wie oben beschrieben, auf Variablen des Applets zugegriffen,in diesem gleichen Zeitfenster übt die Human Resource einen Klick aus auf die obene beschrieben Art und Weiße.

Wird dieser Klick registriert von der JVM und nachdem das Applet wieder freigegeben ist ausgeführt?
Wird dieser Klick überhaupt wargenommen?
Wird dieser Klick ignoriert?

Vielen Dank für ihre kostbare Zeit und Hilfe

Ihr Ihnen ergebener

Herr Maxi Richtig-Korrekt

 

[Wildcard]

synchronized( myApplet){

myApplet.modifiziereVariablen();

}

Dadurch ist nicht das Applet gesperrt. Der Synchronized Block verwendet myApplet als Monitor. Solange der synchronized Block nicht verlassen wird, kann kein anderer synchronized Block mit myApplet als Monitor ausgeführt werden.
Das Applet ist davon selbstverständlich nicht betroffen (ausser es hat einen synchronized(this) Block)

 

[Guest]

Vielen Dank,

auf ihrer Aussage kann ich dann den Schluss ziehen,dass alle Events die durch den Mausklick entstanden sind,welche auch auf myApplet zugreifen, nach Beendigung des Blocks ausgeführt werden?

Vielen herzlichen Dank

 

[Wildcard]

Nein, falsch verstanden.
Die Events werden vom Event Dispatch Thread verteilt. Irgendein anderer Thread der irgendeinen synchronized Block durchläuft hat damit nichts zu tun.

 

[Guest]

hmm jetzt bin ich mir immernochnicht sicher.

sind folgende aussage richtig?

wenn myApplet die Instanz des Applets ist das einer einer Website z.B angezeigt wird, und im hintergrund ein anderer Thread diesen locked können die knöpfe noch gedrückt werden und der jeweilige Event wird ausgelöst?


wen die behandlung des events beinhaltet,dass auf myapplet zugegriffen wird, ist dies erst möglich wenn der andere Thread myapplet freigegeben hat?

 

[Wildcard]

Nein.
Nur synchronized Blöcke die das gleiche Lock verwenden sind überhaupt betroffen.

 

[Guest]

ah okay,das heißt bei meiner Konstellation können Fehler auftreten.

d.h ich sollte lieber die Methoden in der Applet Klasse selber sychronized machen? Sodass myApplet zu 100 % nur von einem Benutzt werden kann

 

[Wildcard]

Dein Applet kann sowieso nur von einem Benutzer verwendet werden, weil es auf dem Client und nicht auf dem Server ausgeführt wird.
Wahllos synchronized zu setzen macht dein Applet im besten Falle langsam, im schlimmsten produzierst du einen Deadlock, der dann nicht nur dein Applet, sondern den Browser gleich mit lahm legt.

 

[Guest]

ja wie soll ich dann vor gleichzeitigem zugriff schützen?

und warum sollte ein anderer thread nicht auf das applet zugreifen können.

sagen wir mal im applet lass ich einen neuen thread starten der der parameter this übergeben kriegt, dann greift der doch genauso auf das applet zu?

Vielleicht reden wir rgad aneinander vorbei hab ich so des gefühl.

applet startet thread -> thread greift via synco auf applet zu. damit ist doch das applet gelockt für andere ? also jedenfalls ist das immer so in java deswegen wunder ich mich warum du sagst es wär nicht so?

 

[Wildcard]

applet startet thread -> thread greift via synco auf applet zu. damit ist doch das applet gelockt für andere ? also jedenfalls ist das immer so in java deswegen wunder ich mich warum du sagst es wär nicht so?

Nein, das ist überhaupt nicht so! synchronized (object) bedeutet nicht, dass object gelockt wird, sondern das object als Lock verwendet wird.

 

[Guest]

hmm wie kann ich mir des dann vorstellen " als lock verwendet wird"? da hängts bei mir grad an der vorstellungskraft

 

[Wildcard]

Stell dir vor du brauchst einen Schlüssel um einen synchronized Block zu öffnen.
object ist ein solcher Schlüssel. Thread a durchläuft einen synchronized Block für den der Schlüssel object erforderlich ist.
Thread a schnappt sich den Schlüssel vom Schlüsselbrett und läuft los.
Thread b kommt auch an einen synchronized Block für den Schlüssel object erforderlich ist.
Nun muss Thread b solange warten, bis Thread a den Schlüssel wieder ans Brett gehängt hat.

 

[Guest]

ah okay, und nehmen wir jetzt mal an thread b greift auf das object zu ohne snycro block, und osnst ist ncoh alles so wie du beschrieben hast.

d.h in fantansiesprache , das b so hart dreist ist und sich auch ins auto setzt obwohl a grad damit fährt um ihn dann voll ins steuer langt die ganze zeit bis mal was passiert und die gegen baum fahren?

heißt also wenn ich das applet schützen will müssten alle threads die darauf zugreifen einen syncro block für das applet benutzen


jetzt stimmts oder?


und bei mri im konkreten fall,sollte ich im event handler nur via syncro auf das applet zugreifen um sich zu gehen dass nix passiert,weil es könnte ja sein dass der thread grad am applet arbeitet?

richtig?

 

[Wildcard]

Du könntest mal das abstrakte 'am applet arbeiten' definieren.

 

[Guest]

ja wenn das applet sagen wir mal die globale variable zaehler hat und ne getter und setter methode. und der event handler und der thread beide auf diese getter und setter zugreifen können. dann um sicherzugehen dass ein gleichzeiter zgriff nicht möglich ist müssten event handler und thread beide mit synchro (myapplet) { blah } drauf zugreifen?

und es reicht nicht wenn blos einer syncro hat?

 

[Wildcard]

und es reicht nicht wenn blos einer syncro hat?

korrekt