Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Knute Johnson Newsgroups: comp.lang.java.programmer Subject: Re: Concurrency question? Date: Sat, 31 Jan 2015 11:23:21 -0800 Organization: A noiseless patient Spider Lines: 52 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 31 Jan 2015 19:22:45 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="aba33539224e5c782fe0c4053f7756fd"; logging-data="6247"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/w3zHwSON+BKiuY3X+Ry+S" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: Cancel-Lock: sha1:FgjZHZ5IKriHVcQA3HpQqi0RkTk= Xref: csiph.com comp.lang.java.programmer:30971 On 1/31/2015 11:04, Eric Sosman wrote: > On 1/31/2015 1:34 PM, Knute Johnson wrote: >> So I have a Map but it could be a List or an Array, >> shouldn't make any difference. Access to the Map is controlled by a >> ReadWriteLock. Several threads read values from the Map and one thread >> can change values or write to or remove key/value pairs from the Map. >> The thread that writes new values to the Map is the EDT, in a >> DocumentListener. One of the reading threads is time consuming and if >> that thread has the read lock the EDT blocks until it can obtain the >> write lock. That can generate noticeable delays in data entry through >> the GUI. >> >> Since data entry is slow it doesn't matter much if the data entry >> changes are available during the time period that the time consuming >> thread is reading the Map. However to ensure that I have current data >> at some point any read access of the Map must be controlled by a read >> lock. >> >> I needed a way to make the time consuming thread not need to hold the >> read lock for the entire time. My solution was to acquire the read lock >> and create a List of values from the Map and return the read lock, this >> is very quick. Then I iterate through the List to perform the time >> consuming task. >> >> I know that it is possible that the GUI could change the Map while the >> time consuming thread is running. That isn't critical as the data would >> be current the next time the time consuming thread ran. The reference >> to the List goes out of scope when the time consuming thread completes. >> Any values that were in the List that were no longer in the Map should >> be available for garbage collection. >> >> Do you see any holes in my logic? Any suggestions? > > Sounds reasonable, on the assumption that out-of-date mappings won't > mess up your time-consuming operation. > > Another possibility would be to buffer on the producer side instead. > Rather than updating the Map directly, the EDT could put the updates on > a queue (quickly) and go about its business. Another thread would wait > for updates to appear on the queue, wait for and grab the write lock, > and then perform the updates. (This is a bit like the write buffers > found in modern CPU's: They don't wait for memory and cache to be > ready, but just stuff the write into a buffer and trust that it will > eventually get flushed to the hard-to-reach backing store.) > I didn't think of that, I like that! I'll play around with it. Thanks! knute...