4

Is it a good design to have X different threads modify X different indices of a list or basically X different threads modifying X different properties of a shared object. I considered using synchronised/synchronisedList(any concurrent datastructure) but I want to avoid the performance overhead that comes with it. Does the approach depend on the value of X?

According to this is multiple threads adding to single arraylist might work but it's not a good design, is it the same with this?

In case the answer varies from language to language, I am asking in particular about JAVA, but would want to know why is it that different languages have this differently.

SHB
  • 589
  • 1
  • 6
  • 18
  • Do the threads share data? – SeverityOne Mar 07 '18 at 08:30
  • So you mean every Thread *x* owns and works exactly on one element of the shared list. Or can two threads access the same element? – lwi Mar 07 '18 at 08:30
  • @lwi Every thread would be working(updating) with only element of the list – SHB Mar 07 '18 at 08:32
  • What exactly is "modify ... indices of a list"? – lexicore Mar 07 '18 at 08:34
  • @lexicore It's basically changing the value at that index. You can assume it as each element of the index is a different counter which gets modified by a different thread. – SHB Mar 07 '18 at 08:37
  • *sort of* `ConcurrentHashMap` does that, threads potentially work on a separate bucket without having to intersect with other threads. but a `CHM` can re-size *while* some thread is working on it... So in theory for a List that is not re-sizeable this could work, but you would need to be sure of the internals of that list – Eugene Mar 07 '18 at 10:01

1 Answers1

2

If we assume that your list has a fixed initial size of let's say 10 elements and you have 10 threads manipulating elements 1 to 10 there is no shared mutual state involved (see shared mutual state is the root of all evil). Thus, I see no big problem with synchronization and would go with the list.

But, keep in mind that this heavily depepends on the operations performed and the size of the list. If you have 1000000 elements inside the list, creating 1000000 threads would be inefficient or even impossible.

Also as soon as you start adding and deleting elements from the list, you have the list itself as shared mutual state and you must now worry about synchronization.

Edit: about shared mutual state

If you shared state that is not mutual you cannot have problems with synchronization because nobody can change the data anyway.

If you have mutual state that is not shared you can change the state but nobody except your current code works on the state anyway, thus the change are directly reflected inside your code.

If you have shared mutual state, your can now have two threads were each one can change the data of the other. In multithreading the order in which this changes happen and a reflected by the reader is not deterministic as long as you do not apply mechanisms such as synchronization or locking. Thus, you can have the classical problems like:

  • A reads data from element x and transforms it.
  • B reads data from element x and transforms it <-- A has not written its changes yet, thus B works with outdated data
  • A writes data to element x
  • B writes data to element x <-- A's changes are lost
lwi
  • 1,682
  • 12
  • 21
  • Expand more about *shared mutable state is the root of all evil* and this plus one from me. – Yahya Mar 07 '18 at 08:41
  • 1
    It depends on which operations are actually performed on the list an the implementation of the list. If threads for instance call `list.set(myIndex, newValue)`, then `list` is a shared mutual state. – lexicore Mar 07 '18 at 08:41
  • @lexicore So is it correct to say that as long as there is no _structural modification_, there will be no issues. Even if there are no issues, is it a good design, or is there a better/recommended way of doing this? – SHB Mar 07 '18 at 08:54
  • @SHB No, not generally. The list is a shared mutual state since threads do share it. So the question is: which operations do threads perform on the list and whether these operations are thread-safe. For instance `get` on an `ArrayList` is fine. – lexicore Mar 07 '18 at 09:06
  • 2
    @SHB As for "is it a good design". Well, I'd prefer functions without side effects. Instead of passing a list and letting the thread modify something in this list, let it just return value directly. But it is hard to say out of the context. – lexicore Mar 07 '18 at 09:09