Java: Mám neprázdný Set, ale nemůžu z něj dostat položky

[Karel Rank]

Pokazdy, kdyz ti vyvratim tvoje tvrzeni, tak prijdes s necim jinym.

Tak ta moje pravdivá tvrzení nevyvracejte a já vám pak nebudu muset pomocí dalších tvrzení dokazovat, že jsou pravdivá.

jestli JVM potrebuje singatures (o tom jsme se nebavili).

Ne, o tom jsme se vůbec nebavili, akorát tím celá debata začala, když jsem vám vysvětloval, že kolekce nemůže použít vlastnosti žádného jiného typu, protože za běhu v JVM je v kolekci jenom typ Object.

Napsal si na zacatku bs, pak ses ho snazil podporit polovicni pravdou a nakonec si hrajes na to, jak mentorujes. Pridavas irelevantni veci a zamotavas se do toho.

Btw, your code suck on github. Machrujes, jak umis bytecoe, ale neohlidas si zakladni veci v kontraktu v tridas co publikujes. What a kind-of-cunt. l33t c0d3r v OKsystems (docela dost lidi te tam nema rado kvuli ego).

Takovy egoisticky idoty jako ty potrebujeme. Jak resis tydle veci s new joiner in the team? A kdyz to fresh from colleage?

[Reklama]

[kvr kvr]

Například v tomhle kódu vám to druhé vlákno může vypsat 0, 1 nebo i hodnotu, kterou měla ta položka ještě dříve.

Kód: [Vybrat]

Item item = synchronizedMap.get("item1");
item.setValue(0);
new Thread(() -> item.setValue(1)).start();
new Thread(() -> System.out.println(item.getValue())).start();

Nemůže. Může vypsat 0, 1 nebo hodnotu, kterou bude mít položka později. Nemůže vypsat dřívější, bo Thread.start() invokuje memory barrier (z hlediska JVM zajišťuje happened-before), podobně jako Thread.join().

[Karel Rank]

Například v tomhle kódu vám to druhé vlákno může vypsat 0, 1 nebo i hodnotu, kterou měla ta položka ještě dříve.

Kód: [Vybrat]

Item item = synchronizedMap.get("item1");
item.setValue(0);
new Thread(() -> item.setValue(1)).start();
new Thread(() -> System.out.println(item.getValue())).start();

Nemůže. Může vypsat 0, 1 nebo hodnotu, kterou bude mít položka později. Nemůže vypsat dřívější, bo Thread.start() invokuje memory barrier (z hlediska JVM zajišťuje happened-before), podobně jako Thread.join().

Bam!

[Lol Phirae]

[Filip Jirsák]

Napsal si na zacatku bs, pak ses ho snazil podporit polovicni pravdou a nakonec si hrajes na to, jak mentorujes. Pridavas irelevantni veci a zamotavas se do toho.

Na začátku jste vy napsal nesmysl, že když se modifikují prvky kolekce, musí být synchronizovány přes stejný monitor. To jsem vám vyvrátil, načež jste začal tvrdit, že kolekce interně pracují i s jinými typy, než je typ Object. A tak to pokračuje dál a dál, vždycky vám vyvrátím jeden nesmysl a vy přijdete s jiným.

[Reklama]

[Filip Jirsák]

Například v tomhle kódu vám to druhé vlákno může vypsat 0, 1 nebo i hodnotu, kterou měla ta položka ještě dříve.

Kód: [Vybrat]

Item item = synchronizedMap.get("item1");
item.setValue(0);
new Thread(() -> item.setValue(1)).start();
new Thread(() -> System.out.println(item.getValue())).start();

Nemůže. Může vypsat 0, 1 nebo hodnotu, kterou bude mít položka později. Nemůže vypsat dřívější, bo Thread.start() invokuje memory barrier (z hlediska JVM zajišťuje happened-before), podobně jako Thread.join().

Já jsem si říkal, jestli ten kód můžu takhle zjednodušit a bude každému jasné, že jde jenom o ten princip, že vytažení prvku ze synchronizované kolekce neříká vůbec nic o synchronizaci toho prvku. Ale máte pravdu, měl jsem buď ten text upravit, aby přesně popisoval ten kód, a nebo nechat ta vlákna nastartovaná dříve, aby tam opravdu nebyla žádná paměťová bariéra.

[Ondrej Nemecek]

Ale špatná synchronizace přístupu při změně té fronty by neměla vést k trvalé nepoužitelnosti té fronty, ne? Takže jeden problém je, zda je synchronizace v pořádku a druhý problém je, jakto že se ta fronta dostane do nevalidního stavu (není prázdná ale nemůžu dostat její prvky a to ani při pozastavených vláknech jvm).

Tomu se rika race condition. Brian Goetz napsal skvelou knizku https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601. Je ted ve sleve za $15. Stalo by zato si ji precist nez delat zavery, ze kdyz neco modifikuju pres nekolik threadu bez synchronizace, tak to nemuzu rozbit. Proto jsem psal, ze si hrajes na Doug Lea

Aha, dobře, díky za vysvětlení příspěvku. Problém nebyla absence synchronizace, ale špatná synchronizace (přes špatný objekt). Závěry jsem nedělal, ptal jsem se a odpověď jsem dostal již na cca druhé stránce této diskuze, totiž že se rozjede počítadlo se skutečným počtem prvků.

Na jiny masine to muze vypadat jinak. Proto je to race condition. A je jedno jestli to je absenci synchronizace nebo spatny synchronizaci.

Rozdíl je v tom, že v druhém případě je jasné, že si od začátku uvědomuju nutnost synchronizace akorát jsem ji (pod dojmem toho nepravého singelotnu) špatně provedl. A reaguju tím na vaše doporučení, abych to udělal thread-safe, což už je v diskuzi dávno zmíněno - poprvé v mém původním dotazu a posléze potvrzeno ostatními. Mimo jiné právě proto jsem nerozuměl, co svým příspěvkem vlastně chcete říct, přišlo mi to jako takový výstřel do tmy 

[Karel Rank]

Napsal si na zacatku bs, pak ses ho snazil podporit polovicni pravdou a nakonec si hrajes na to, jak mentorujes. Pridavas irelevantni veci a zamotavas se do toho.

Na začátku jste vy napsal nesmysl, že když se modifikují prvky kolekce, musí být synchronizovány přes stejný monitor. To jsem vám vyvrátil, načež jste začal tvrdit, že kolekce interně pracují i s jinými typy, než je typ Object. A tak to pokračuje dál a dál, vždycky vám vyvrátím jeden nesmysl a vy přijdete s jiným.

Ne nevyvratil. Pridal si do toho deadlock. O kterym jsme se opet nebavili. Je to jen show-off od tebe.

[Karel Rank]

Ale špatná synchronizace přístupu při změně té fronty by neměla vést k trvalé nepoužitelnosti té fronty, ne? Takže jeden problém je, zda je synchronizace v pořádku a druhý problém je, jakto že se ta fronta dostane do nevalidního stavu (není prázdná ale nemůžu dostat její prvky a to ani při pozastavených vláknech jvm).

Tomu se rika race condition. Brian Goetz napsal skvelou knizku https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601. Je ted ve sleve za $15. Stalo by zato si ji precist nez delat zavery, ze kdyz neco modifikuju pres nekolik threadu bez synchronizace, tak to nemuzu rozbit. Proto jsem psal, ze si hrajes na Doug Lea

Aha, dobře, díky za vysvětlení příspěvku. Problém nebyla absence synchronizace, ale špatná synchronizace (přes špatný objekt). Závěry jsem nedělal, ptal jsem se a odpověď jsem dostal již na cca druhé stránce této diskuze, totiž že se rozjede počítadlo se skutečným počtem prvků.

Na jiny masine to muze vypadat jinak. Proto je to race condition. A je jedno jestli to je absenci synchronizace nebo spatny synchronizaci.

Rozdíl je v tom, že v druhém případě je jasné, že si od začátku uvědomuju nutnost synchronizace akorát jsem ji (pod dojmem toho nepravého singelotnu) špatně provedl. A reaguju tím na vaše doporučení, abych to udělal thread-safe, což už je v diskuzi dávno zmíněno - poprvé v mém původním dotazu a posléze potvrzeno ostatními. Mimo jiné právě proto jsem nerozuměl, co svým příspěvkem vlastně chcete říct, přišlo mi to jako takový výstřel do tmy 

Precetl jsem si jen prvni stranku. A reagoval. Dal jsem to i do statement.

Tu knizku ti muzu poslat. Bude to i s postovnym asi $28. Dej vedet.

[Filip Jirsák]

Ne nevyvratil. Pridal si do toho deadlock. O kterym jsme se opet nebavili. Je to jen show-off od tebe.

Chcete tvrdit, že když máte mapu definovanou následujícím způsobem:

Kód: [Vybrat]

Map<String, AtomicLong> counter = new HashMap<>()

a chcete tu mapu i její prvky modifikovat z více vláken, musíte modifikaci prvků synchronizovat přes stejný monitor, jako přístup k mapě? Podle vás je následující kód špatně?

Kód: [Vybrat]

public long increment(String name) {
  AtomicLong namedCounter;
  try {
    lock.readLock().lock();
    namedCounter = counter.get(name);
  } finally {
    lock.readLock().unlock();
  }
  return namedCounter.incrementAndGet();
}

Jak by ten kód byl podle vás správně, aby se increment() dalo volat bezpečně z více vláken?

[kvr kvr]

Podle vás je následující kód špatně?

Ano, je špatně. Správně má být:

Kód: [Vybrat]

public long increment(String name) {
  AtomicLong namedCounter;
  lock.readLock().lock();
  try {
    namedCounter = counter.get(name);
  } finally {
    lock.readLock().unlock();
  }
  return namedCounter.incrementAndGet();
}

[Karel Rank]

Podle vás je následující kód špatně?

Ano, je špatně. Správně má být:

Kód: [Vybrat]

public long increment(String name) {
  AtomicLong namedCounter;
  lock.readLock().lock();
  try {
    namedCounter = counter.get(name);
  } finally {
    lock.readLock().unlock();
  }
  return namedCounter.incrementAndGet();
}

A hodi ti to NPE kdyz neexistuje name[\tt] v mape.

Snazis se furt dokazat, ze mas polovicni znalosti JLS, JMM a pouzivas je jak se ti to hodi?

[Filip Jirsák]

Fajn. Volání incrementAndGet() ten element kolekce modifikuje. Volání incrementAndGet() není synchronizováno přes stejný monitor jako kolekce ani jako jiné elementy kolekce. Takže jste sám uvedl protipříklad vyvracející pravdivost vašeho tvrzení „Jestli se modifikujou elementy kolekce, tak musi byt samozrejme synchronizovany pres stejny monitor.“

[Ondrej Nemecek]

Precetl jsem si jen prvni stranku. A reagoval. Dal jsem to i do statement.

Samozřejmě vím, že jste to uvedl. A já se zeptal, co tím příspěvkem vlastně myslíte, když to je už vyřešené.

Uzavřeme to: Synchronizoval jsem přes špatný zámek, protože jsem mylně předpokládal tvrdý singleton. Tím vznikla race condition v kokurenčním multi-threaded prostředí a ta mě vypekla. Po změně zámku to funguje. V diskuzi dále zazněly další doporučení, jak aplikaci pro dané použití lépe strukturovat a byla doporučena literatura. To je ta část diskuze, která pro mě měla smysl.

Tu knizku ti muzu poslat. Bude to i s postovnym asi $28. Dej vedet.

Děkuju, vystačím s tím co mám.