Zu sagen das "nebenläufiges Warten" wirklich nebenläufig wäre ist ein Widerspruch.
Der worin liegt? Ein Prozess kann neben einem anderen ausgeführt werden (ist damit nebenläufig) und kann warten (z.B. weil ein Sleep das verlangt). Trotzdem sind die beiden Prozesse nebenläufig. Nebenläufigkeit sagt gerade nicht, dass immer etwas läuft (auch wenn das im Namen steckt).
Es gibt neben den synchronisierten Collections die eben darauf beruhen dass Threads sequenziert werden
Sorry, aber die Collection Klassen haben nichts, aber wirklich gar nichts mit der Nebenläufigkeit zu tun. Das Verhalten von nebenläufigen Prozessen (leichtgewichtig Threads) wird hier gesteuert oder auch nicht, aber ich kann eine ArrayList genauso in einem nebenläufigen Programm einsetzen wie einen Vektor oder eine Skiplist. Die Nebenläufigkeit interessiert das nicht im geringsten.
Die ist allein durch die Verwendung eines einzelnen oder mehrerer Prozesse definiert (ob implizit oder explizit ist dann noch ein anderes Thema).
und den unsynkronisierten Collections gibt es auch welche die für Nebenläufigkeit ausgelegt sind im java.util.concurrent Package, einfach mal nachsehen
Nehmen wir hier doch die Beschreibung der Klasse SyncronousQueue, da lese ich:
Java API hat gesagt.:
A blocking queue in which each insert operation must wait for a corresponding remove operation by another thread, and vice versa.
Na nu, da wartet ein Thread? Im nebenläufigen Paket? Ist die Klasse falsch einsortiert, mein englisch zu schlecht oder wo liegt jetzt der Fehler?!
maki hat gesagt.:
da werden u.a. sog. "Skiplists" eingesetzt, diese basieren auf wartefreien Algorythmen, dass sind wirklich nebenläufige Collections.
Eine Skiplist sehe ich auch nicht, aber Varianten des Map und Set Interface, keine für eine Liste.
maki hat gesagt.:
Es gibt es einen unterschied zwischen Nebenläufig und synchronisiert
Dass hatten wir auch schon, sieh mal in Deinem Beitrag weiter oben, Nebenläufigkeit sagt etwas über mehrere Threads aus, die gleichzeitig laufen, synchronisiert hingegen hat was mit der Steuerung des Zugriffs zu tun. Das wurde aber schon gesagt, natürlich kann man auch in einem nicht-nebenläufigen Programm synchronisieren (kostet unnötig Zeit, aber ist möglich, wurde nie anders behauptet).
maki hat gesagt.:
Threadsafe git es in mind. 2 Varianten, aber nebenläufig (engl. "concurrent") ist nicht synchronisiert.
Was ist genau Dein Problem? Ich sehe überhaupt nicht worauf Du hier noch hinaus willst. Bier gibt es in Dunkel und Hell aber concurrent heißt auf Deutsch nebenläufig. Ob es Threadsafe in 2 oder 5 Varianten gibt ist doch völlig unerheblich für den Rest der Aussage. Nebenläufigkeit ist nicht Synchronisation, ja, stimmt. Aber wer hat das behauptet? Du sagst doch selbst:
maki hat gesagt.:
Synchronisiert ist eben nicht nebenläufig sondern das sequenzieren von Threads, hast du ja selber beschrieben.
maki hat gesagt.:
Dazu kommt dass alle sychronisierten Collections (zB. durch java.util.Collections) nochmals eine externe synchronisation bei Nutzung des Iterators benötigen, sonst fliegt bald eine ConcurrentModificationException.
Und hier wird es mir langsam auch zu blöd. Ich habe gesagt und sage auch weiterhin, dass die Zugriffe auf die Klasse Vector nebenläufig unproblematisch sind. Ein Iterator ist kein Vector. Die Klasse X, die einen Vector verwendet ist auch nicht thread-safe, nur weil ein Element dadrin thread-safe ist. Das ist klar und Du hast Recht.
Da ich es offensichtlich behauptet habe (bitte reiche die Stelle nach an der das geschehen ist, ich kenne sie nicht) möchte ich natürlich ergänzen, dass zwar der Aufruf der Methode firstElement() oder lastElement() thread-safe ist, aber Aufrufe der Methoden des zurückgelieferten Elements sind es nicht automatisch. Achtung, das kann auch für andere Methoden gelten, zum Beispiel kann man sich ein Array zurückgeben lassen und auch dieses ist ggf. nicht thread-safe. Und hey, maki sagte dass die Klassen aus dem Package java.util.concurrent Nebenläufig sein, aber Achtung, auch hier sind nicht alle Rückgabewerte thread-safe sondern nur die Aufrufe der Methoden der Klassen in dem Package.
Sorry, mir wird das langsam einfach zu blöd. Wenn Du hier sagst, dass Nebenläufigkeit nicht synchronisiert heißt, dann stimme ich Dir zu und habe nie das Gegenteil behauptet. Wenn Du sagst, dass Synchronisation für Objekte Sinn macht, auf welche nicht nebenläufig zugegriffen werden, dann hätten wir unterschiedliche Ansichten. Um es noch mal klar zu sagen, es ist möglich, aber nicht sinnvoll, da man sehr teure Operationen für die Synchronisation bemüht ohne dass sie einen Nutzen hätten.
Wenn Du sagst thread-safe ist nicht gleich zu setzen mit Synchronisation oder Nebenläufigkeit, dann stimme ich Dir zu, denn es mit thread-safe wird nur eine Eigenschaft bezeichnet, die eben sagt dass nebenläufige Zugriffe ohne weitere Synchronisation problemfrei möglich sind.
Beim Besten willen heißt Nebenläufigkeit aber nicht dass zwei Threads immer parallel laufen und sich nicht gegenseitig blockieren dürfen. Und nur weil ein Thread auf die Freigabe einer Ressource durch einen anderen Thread wartet ist die Nebenläufigkeit nicht aufgehoben (sonst erklär mir mal Deadlocks...).
Obwohl ich das Gefühl habe, dass wir schon mehr als OT sind, eine Frage die ich wirklich hätte (die ist dann auch weniger OT), Du sagst ja:
maki hat gesagt.:
da werden u.a. sog. "Skiplists" eingesetzt, diese basieren auf wartefreien Algorythmen, dass sind wirklich nebenläufige Collections.
Ich hab jetzt nichts dazu gefunden, aber kannst Du mir hier bitte sagen, wie die Algorithmen da wartefrei arbeiten? Ganz ehrlich, würde mich interessieren! Ich kenne hier einfach keinen Ansatz der funktionieren würde, der komplett ohne blockierendes Warten auskommt. Oder arbeiten die nur asynchron, kehren also ggf. sofort zurück, während intern immer noch blockierend gewartet wird?
