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

Groups > comp.lang.java.programmer > #30972

Re: Concurrency question?

Show all headers | View raw

On 1/31/2015 11:12, Arne Vajhøj wrote:
> On 1/31/2015 1:34 PM, Knute Johnson wrote:
>> So I have a Map<Integer,String> 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?
>
> If the data structure is small, then having the updater create a clone
> and update that could provide adequate performance and a very
> simple programming model.
>
> Arne

The records are 34 bytes and there can be no more than 10,000 of them. 
In reality the will be no more than a few hundred records at any given time.

I'll think about that, thanks Arne.

knute...

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Concurrency question? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-01-31 10:34 -0800
  Re: Concurrency question? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-01-31 14:04 -0500
    Re: Concurrency question? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-01-31 11:23 -0800
  Re: Concurrency question? Arne Vajhøj <arne@vajhoej.dk> - 2015-01-31 14:12 -0500
    Re: Concurrency question? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-01-31 11:33 -0800
  Re: Concurrency question? v_borchert@despammed.com (Volker Borchert) - 2015-01-31 19:20 +0000
    Re: Concurrency question? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-01-31 15:42 -0500
      Re: Concurrency question? Knute Johnson <eternal@knutejohnson.com> - 2015-01-31 19:51 -0800
        Re: Concurrency question? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-02-01 09:24 -0500
  Re: Concurrency question? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-01-31 22:59 -0800
    Re: Concurrency question? Arne Vajhøj <arne@vajhoej.dk> - 2015-02-01 12:55 -0500
      Re: Concurrency question? Silvio <silvio@internet.com> - 2015-02-01 22:19 +0100
      Re: Concurrency question? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-02-06 22:29 -0800
        Re: Concurrency question? Knute Johnson <eternal@knutejohnson.com> - 2015-02-07 10:14 -0800
        Re: Concurrency question? Robert Klemme <shortcutter@googlemail.com> - 2015-02-08 19:33 +0100
  Re: Concurrency question? olupot douglas <olupotd3@gmail.com> - 2015-02-07 01:06 -0800
  Re: Concurrency question? Haddock <ffm2002@web.de> - 2015-02-16 06:32 -0800

csiph-web