Competition and memory sharing between Threads

Question

I have the following code:

class Objt
{
    public List<t> list_t1;
    public List<t> list_t2;

    public Objt() 
    {
        // faz inicializações
    }

    public void handleLists(List<t> list)
    {
        for(t e: list)
        {
           ... // manipula elementos da lista
        {
    }
}

Problem: I am free to manipulate both lists at the same time in my problem, including that is the intention. In this code above, only one thread can enter this line of code of this object at a time to manipulate a list, the other would be waiting to manipulate another list.

Question: I could well duplicate this method handleLists() and name them handleList1() and handleList2() and allocate them each to a thread, but it’s kind of tricky, isn’t it? Is there a more elegant solution? A Pattern?

What I want to understand now, given the comments, is whether I can use the same method handleLists() in both threads just passing different lists for each thread and they will execute in parallel.

Note: I had put list_t1 and list_t2 just to illustrate a possible use.

Answer 1

Piovezan’s answer gives a great explanation of the problem he is having in the use of the method, so I will just supplement with the part I understood different in the question (which in passing is not very clear at this point).

If the method will simultaneously receive different lists, in case a call in a thread will receive list_t1 and the other call in another thread will receive list_t2 and the method will not manipulate the parameter list which will contain either one or the other list on each call, they will not get confused, are called completely isolated and there will be no competition problems. Therefore, not only is there no problem in calling this method in more than one thread simultaneously, achieving parallelism, as neither need mark it as synchronized. You won’t even need to synchronize anything internally, which can even end parallelism depending on how it’s used (I’ve already talked about this).

Of course it may not be quite this depending on the content of the method, which was not posted.

As an addition, creating another method will not help at all. In fact, depending on what you do, it can even bring more problems.

Answer 2

In my experience it is not common for you to have two independent lists requiring synchronized access to an object. It may be evidence of a violation of the Single Liability Principle. But this is a design issue and does not come to the point.

Keep in mind that the synchronized access to a code snippet depends on a "token", that is, an object of which there is only one instance, so that whoever has it at any given time can perform the desired action, otherwise you will have to wait for the owner of the token release him so he can acquire that token and perform the action. Except that the term used is not "token" but "lock" (or semaphore, monitor, etc.). What I mean is that his job is to be a token. This is what synchronized access is all about: the thread who owns the lock can enter the synchronized code snippet and execute it (and perform operations on your lists, for example).

Any object can be a "lock". When a method is synchronized, the lock is the very object that contains that method. In the case of your example, if you have such a code...

Objt bijeto = new Objt();
bijeto.handleLists(list);

...the object bijeto lock for the synchronized method handleLists().

The choice of lock (or of Locks) most appropriate(s) for your case will depend on your intention. When a thread has access to list_t1, you want him to also have access to list_t2? In this case, you can use a lock only for both lists. This lock can be the object itself Objt, or another object you define as an attribute of Objt.

Or when a thread has access to list_t1, you don’t want him to have access to list_t2? Then you’ll need two Locks different. The lists themselves, if they are non-null and declared as final, can be used as Locks for access to themselves. Or else you can create two attributes lock_t1 and lock_t2.

Note that the two code snippets below are equivalent:

Stretch 1:

public class Objt {

    public synchronized handleList() {
        ...
    }
}

Stretch 2:

public class Objt {

    public handleList() {
        synchronized(this) { // "this" é referência para o próprio
            ...              // objeto de classe Objt
        }
    }
}

---

Editing:

You clarified that you want to have a method that takes a list as a parameter and makes changes to it. A thread will call this method by passing a list list_t1 as a parameter and another thread will call this method by passing another list list_t2 as a parameter.

In this case IF this is the only point where the lists are modified, the parallelism will work smoothly and there will be no need to declare the method synchronized, as @Maniero said in his reply, which perfectly answers the question. It will work because the method is not making any changes in shared state, only in the state of the parameters passed to it, which in this case are independent of each other.

But avoid declaring the lists in the class that contains this same method, this only creates confusion (because if they are attributes of a class it would not be necessary to pass them as a parameter to methods of that same class).

Or else stop declaring everything as public and try to learn how to use Java access modifiers to correctly reflect your intentions in the code.

If you want to make the code more elegant, give more details about what you want to do and include more code in the question, including threads who call such a method, that we show you how it can stay.