0

I have an ArrayList which I add items to, within a broadcastreceiver callback.

However the arraylist will eventually be attached to an adapter and then I wish to display the contents of the array to the screen.

The array contains peer information from a P2P app I'm working on so it will be subject to change frequently as devices drop in and out of connection/range.

So basically the arraylist will be read and written to frequently. I come from a c++ background so I would normally use a lock to protect my arraylist, when accessing it, but I'm unsure what I should use in java/android. Any Advice please.

bwegs
  • 3,769
  • 2
  • 30
  • 33
Bluemoon10
  • 89
  • 5
  • I suggest that, once you get a satisfactory answer to this question, you reconsider your architecture instead of using it. If you actually use some kind of synchronization to control access to that list, your UI is gonna be janky as all get out. – G. Blake Meike Jul 05 '14 at 16:33

3 Answers3

1

Use a BlockingQueue instead of an ArrayList. It'll make your list Thread safe. As per the Documenatation :

A Queue that additionally supports operations that wait for the queue to become non-empty when retrieving an element, and wait for space to become available in the queue when storing an element.

CodeWarrior
  • 5,026
  • 6
  • 30
  • 46
  • 1
    It will make it threadsafe for single additions. If he needs bulk addition/removal of information it may not be enough – Gabe Sechan Jul 05 '14 at 15:24
  • @GabeSechan I've been using it for bulk data and it works just fine. kindly suggest a better option if it may fail. – CodeWarrior Jul 05 '14 at 15:28
  • You can't use it for bulk data- a synchronized data structure works fine for a single function call. If you need to make 4 add calls and don't want the other thread to see the changes until all 4 are made, you need to lock the structure in some way. Otherwise the other thread can access it in between function calls. – Gabe Sechan Jul 05 '14 at 15:29
1

Using a lock is never wrong. All synchronized does is use a lock under the hood. Some Java purists may complain, but you tend to get more flexibility out of just using a semaphore (and sometimes its just the only way to be correct). There's also some ugly corner cases to wait/notify that you have to really understand the use cases of to get right that semaphores just avoid. If you're familiar with them I wouldn't hesitate to use it just because you're in Java now.

Gabe Sechan
  • 90,003
  • 9
  • 87
  • 127
0

The synchronized keyword locks on whatever object is specified. If the method is marked as synchronized and its an instance method it locks on the enclosing instance. If the method is static, it locks on the class object. If an object is specified in parentheses after the synchronized keyword in a syncrhonized block, the lock is held on that object. I would typically use a thread safe collection like AndroidWarrior proposed, but if thats not possible, just make sure that your accessors and mutators lock on the same object.

Mark W
  • 2,791
  • 1
  • 21
  • 44