Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.java > #13141

Re: Parallelprogrammierung

Path csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From "Christian H. Kuhn" <qno-news@qno.de>
Newsgroups de.comp.lang.java
Subject Re: Parallelprogrammierung
Date Tue, 3 Oct 2017 15:40:32 +0200
Lines 40
Message-ID <f3hiahFjtstU1@mid.individual.net> (permalink)
References <f2naabFfb7jU1@mid.individual.net> <oq7qee$duf$1@gwaiyur.mb-net.net>
Mime-Version 1.0
Content-Type text/plain; charset=iso-8859-15
Content-Transfer-Encoding 8bit
X-Trace individual.net v3iMt+LDTyXDPt3SEj6H6gkIgJLmirYzKom/N5Ntpwmm6fals=
Cancel-Lock sha1:zHE+cnoB2z4vZneyuZ6l4VlAur8=
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
In-Reply-To <oq7qee$duf$1@gwaiyur.mb-net.net>
Xref csiph.com de.comp.lang.java:13141

Show key headers only | View raw


Am 24.09.2017 um 10:30 schrieb Marcel Mueller:
> On 23.09.17 16.44, Christian H. Kuhn wrote:
>> exportData() und importData() schließen sich gegenseitig aus. Das bekäme
>> ich mit synchronized hin. Aber.
>>
>> Es sollen mehrere Threads exportData() aufrufen können, ohne aufeinander
>> warten zu müssen.
> 
> Dur suchst ein ->ReadWriteLock.

In der Tat. Vielen Dank! ReentrantReadWriteLock; importData() macht
einen writeLock().lock(), exportData() einen readLock().tryLock(). Das,
was danach kommt, steht sowieso in einem try-with-resources-Block, da
ist das finally mit dem jeweiligen unlock() kein Problem.

>> Alles, was ich an Literatur zur Parallelprogrammierung gefunden habe,
>> geht davon aus, dass immer nur ein Thread im kritischen Bereich sein
>> darf.
> 
> Dann hast Du zu wenig gesehen. ;-)

Da sind wir uns einig :-)

> Bibliotheken sollten niemals Exceptions in Standardsituationen werfen.
> Dafür sind sie zu teuer. Und daran halten sich die Standard
> Lock-Implementierungen auch.

Wenn List<String[]> exportData(String, String) den Lock nicht bekommt,
gibt es null zurück. Wer fremde Bibliotheken aufruft und nicht auf null
checkt, hat es nicht besser verdient ;-)

Und nachdem das geklärt ist, ist mir aufgefallen, dass auch andere
Rechner ihre (eingeschränkten) QDatabase-Objekte mit ihren spezifischen
Clients auf die Datenbank zugreifen und nicht über den Prozess, in dem
mein QDatabase-Objekt die Locks verwaltet. Ich darf also noch Locks auf
die Tabellen in Postgresql setzen. Andere Gruppe.

lg
QNo

Back to de.comp.lang.java | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Parallelprogrammierung "Christian H. Kuhn" <qno-news@qno.de> - 2017-09-23 16:44 +0200
  Re: Parallelprogrammierung Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-09-24 10:30 +0200
    Re: Parallelprogrammierung "Christian H. Kuhn" <qno-news@qno.de> - 2017-10-03 15:40 +0200
      Re: Parallelprogrammierung Patrick Roemer <sangamon@netcologne.de> - 2017-10-03 20:15 +0200
        Re: Parallelprogrammierung Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-08 22:15 +0200
          Re: Parallelprogrammierung Patrick Roemer <sangamon@netcologne.de> - 2017-10-09 12:36 +0200
          Re: Parallelprogrammierung "Christian H. Kuhn" <qno-news@qno.de> - 2017-10-12 20:23 +0200
            Re: Parallelprogrammierung Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-13 09:01 +0200

csiph-web