Let us consider a system with multiple locks. Let us say that process A wants to acquire a lock.
The traditional method is to contend for the lock and ultimately get it. Instead of this, can we do
something different? Can we give the task that needs to be performed to the thread that currently
has the lock? In this case, there is no need to acquire the lock. How do we achieve this, and ensure
that the approach is fast, efficient, and fair. Let us assume that a task is represented by a class,
which has a single method, run. We can then just pass an instance of the class. Let us now depict a
case that can happen. Thread A has the lock, and thread B wants to acquire it. Thread B gives its
task to thread A. By that time thread A has unlocked and left. Thread B will wait forever. We need
to handle such special cases
- 7,746
- 2
- 28
- 38
-
1Why write in that weird, first person academic tone? It just makes it read like a homework problem and in this case makes it harder to read. – Mdev May 09 '14 at 09:46
-
I guess you are talking about queueing, right?? – prasanth May 09 '14 at 09:56
-
I think your question is too general for stackoverflow. If you are trying to solve a specific problem, then post the code that you wrote to solve it, tell us why you are not happy with your solution, and ask whether anyone can see a better solution. – Solomon Slow May 09 '14 at 14:04
-
@Human that's because it is. Here's one of his classmates with an exact duplicate: http://stackoverflow.com/questions/23571683/art-of-multiprocessor-programming – Mark Amery May 09 '14 at 18:52
1 Answers
Thread communication can be achieved in several different ways, like Queue, Ring Buffer, etc. Normally, contending a lock represents the default way to collaborate over a shared resource but it does not scale as approach.
The approach proposed consisting in sharing a task can be thought in terms of collaboration by the mean of a communication. In this scenario, Thread A receives a task from Thread B, let's say upon the Queue X, upon the completion Thread A responds to Thread B upon the Queue Y. Like this, there is no Lock to acquire, assuming that the Queues are already synchronized or Thread-safe (e.g. concurrent versions since Java 1.5).
Summarizing, it is needed to distinguish between the two cases: cooperation by the mean of 1. a Lock or 2. Communication (i.e. task exchange according to your example). This is the basic way to face this kind of problem. Anyway, if you are more precise in defining the scenario, maybe it would be easier for us to help you designing your concurrency solution/algorithm.
- 7,396
- 4
- 34
- 30