Jump to content
  • Advertisement
Sign in to follow this  
tom_mai78101

Unity [Java] Wait() / Notify() order of execution: The placement of these two methods are different from common examples.

This topic is 2543 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Here's a working non-deadlock code of having four threads running the same Runnable method.
[source lang="java"]
package concept;

//Generic Process
public class GenericProcess implements Runnable
{
private int number;

public Object lock;

public GenericProcess setValue(int value)
{
number = value;
return this;
}

public GenericProcess(Object obj)
{
lock = obj;
}

@Override
public void run()
{
while (true)
{
synchronized (lock)
{
lock.notify();
if (Thread.holdsLock(lock))
{
try
{
System.out.println(this.getClass() + " " + number + " has the lock.");
lock.wait();
}
catch (InterruptedException e)
{
e.printStackTrace();
}
}
}

}

}
}

[/source]

I questioned the order of execution of both wait() and notify(). Some examples found by Googling place notify() underneath wait(); wait() executes first, then notify(). Some examples include boolean flags to detect execution, and also executes wait() first before notify().

Without any boolean flags or something to detect if the thread is executing during its quantum time frame, I forced myself to try making a small mutex that allows any threads to simply execute this while loop.

Am I doing it correctly, if compared to some Java concurrency guidelines which have a larger acceptence among the developer community? Why do people put notify() underneath wait() by some lines of code, by making notify() to appear near the end of synchronized methods or Object references? For the second question, why are they (the codes) be designed like that?

Thanks in advance.


Share this post


Link to post
Share on other sites
Advertisement
What exactly is this code supposed to do? Racing to hold the lock doesn't make much sense and spinlocks are bad enough as it is.

Share this post


Link to post
Share on other sites

What exactly is this code supposed to do? Racing to hold the lock doesn't make much sense and spinlocks are bad enough as it is.


Good question. Today, I asked my classmate what our professor wants us to do. He said all I have to do is just calculate any kind of scheduling algorithms, like FCFS, Shortest Job First, or use Round-robin scheduling, depending on whether I do preemptive or nonpremptive. In short, I have no clue still. Ask 4 different classmates, and they all replied the same negative answer.

My code above was, not is (unsure of its status), about trying to schedule 4 threads running in 1 lock, to try and make all 4 threads to execute in specific order, like:

t1 -> t2 -> t3 -> t4.

I always get t2 -> t0 -> t1 -> t3, and repeat. If I were to place a scheduling scheme (don't know at the moment) in, it might run the 4 threads to execute in a fashionly order. That above was my basis (motive) to making this code to work, and I worked on it until I get the message that probably a large portion of the class have no clue on what our professor wants us to do.

If I don't try doing a spinlock, I supposely don't know how to force a thread to come out of the waiting state, and I'm still a beginner when it comes to Java synchronized programming. With the aid of Google, a lot of Java wait()/notify() articles and 5 hours to grind, my progress so far is just about it, that piece of code above is what I make most of my time into, from scratch.

What do I do with my 4 threads and this lock? Thanks in advance.

Share this post


Link to post
Share on other sites

He said all I have to do is just calculate any kind of scheduling algorithms, like FCFS, Shortest Job First, or use Round-robin scheduling


None of this has anything to do with threads. Schedulers are almost always single-threaded. Efficient concurrent schedulers are incredibly difficult to implement.

to try and make all 4 threads to execute in specific order, like: [/quote]

Remove the threads, sort the tasks, run them sequentially.

it might run the 4 threads to execute in a fashionly order.[/quote]

Trying to get non-deterministic, non-realtime OS to execute threads in specific order is a recipe for dead- or live-lock. First step with such problems is to build a DAG, perform topological sort, then progress by level. Most of this cannot be done by userland process since threading states and thread dependencies and lock information isn't readily available. Or, ignore OS scheduler and implement own scheduler that runs in single thread, which is what large majority of language interpreters and VMs does these days.

What do I do with my 4 threads and this lock?[/quote]Delete them.


Scheduling problem can be formulated like this:interface Job {
bool execute_for(int duration); // returns true if it completed, false if more work is to be done
int remaining(); // optional, not always known, returns amount of work left
}
Job could be a thread (nothing to do with Java Thread class), a process or some other resource.

The algorithm then looks like this:
Job selectNext(List<Job> jobs);
int getSliceFor(Job j);

while (true) {
Job next = selectNext(jobs);
bool done = next.execute_for(getSliceFor(next));
if (done) jobs.remove(next);
}

You now need to implement two methods. selectNext() chooses the next job to run.
getSliceFor() determines for how long a given job should run at most. That can be simple fixed value (100ms) or some advanced algorithm, which may take into account statistics of previous runs, priority, remaining work to be done, ...

In a real OS threads would keep on running and scheduler would interrupt them. Since such facilities aren't available, we simulate this behavior by having jobs stop by themselves (execute_for). This is still pre-emptive scheduling, we just simulate the difficult part.

For cooperative scheduling, executeFor would not be given time parameter, but list of Jobs. It would then call execute_for() itself. If a job decided to not do that, the system would hang. If it wouldn't do that in timely manner, system would become unresponsive. Difference is mostly in where the selectNext() gets called.

Round robin version:
Job selectNext(List<Job> jobs) {
Job next = jobs.remove(0); // remove first job
jobs.add(next); // append it to end of list
return next;
}

int getSliceFor(Job j) {
return 100;
}


Jobs take turns, each runs for predefined amount of time. If List<> passed into selectNext is LinkedList, the example has O(1) complexity, but main loop would still have O(n). These are details related to how List<Job> is implemented, they need to be addressed separately.

An implementation of such system could use the following definition:class JobX : implements Job {

private int amount_left;
private int hidden;
public JobX() {
amount_left = random(1, 200000); // random value between these values
hidden = random(0, 5) == 0; // hidden jobs don't know how much time they need
}
bool execute_for(int duration) {
amount_left -= duration;
return (amount_left < 0);
}
int remaining() {
return (hidden ? -1 : amount_left);
}
}

Share this post


Link to post
Share on other sites
I thank you for the amount of helpful tips from your post. I just can't stress myself from not thanking you enough. :D

Looks like I need to teach myself some other scheduling algorithms first, before heading towards making threads, or maybe I need to learn how to grasp a starting point in the area of new knowledge.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!