| Eclipse Job framework: FIFO queue that respects priority? [message #545408] |
Wed, 07 July 2010 12:34  |
Eclipse User |
|
|
|
Hi All.
I would like to implement a FIFO queue using the Eclipse Job framework. The
jobs should be performed one by one and no jobs should be performed at the
same time as others. To implement this I can use the
ISchedulingRule#isConflicting and compare a timestamp of the two jobs.
However, I would still like to be able to set the priority of a job
(Job#setPriority). So if I schedule a list of jobs: A,B,C,D and D has high
priority then D should be performed first when all the jobs are waiting the
be executed. As far as I can see this is not possible because the JobManager
class initializes the instance variable "waiting" as "waiting = new
JobQueue(false);". The false means "allowConflictOvertaking", so in the
queue of waiting runners it is not allowed to overtake conflicting job. But
I have to make the jobs conflicting to get the FIFO behaviour. How can I get
a FIFO queue that respects the priority property?
Thanks in advance,
Anders Baumann
|
|
|
| Re: Eclipse Job framework: FIFO queue that respects priority? [message #545488 is a reply to message #545408] |
Wed, 07 July 2010 23:07  |
| Eclipse User |
|
|
|
It sounds like you've already implemented a scheduling rule that compares timestamps. Maybe that rule should first compare the priorities, and then only compare timestamps when the priorities are equal.
It's funny, I just implemented a similar scheduling rule today. I have jobs A and B, and I want B to only be scheduled after A has been completed. However, I ran into a problem. I'm doing:
A.schedule(8000);
B.schedule();
But since A is scheduled with a delay, I have problems. Unfortunately, it seems like the scheduling rule for B is only consulted if A is currently running. But since A was delayed, B gets scheduled and runs before A.
If this is how scheduling rules work, then they aren't really useful for scheduling. Actually, aren't they just mutexes? The rules I used for jobs A and B aren't symmetric, but the javadoc for isConflicting() says that the method must be symmetric, which again sounds more like a mutex.
I'd like to be told otherwise, but it sounds like if you want to guarantee the order in which jobs run, you have to do your own scheduling and only use ISchedulingRule for avoiding deadlocks.
|
|
|
| Re: Eclipse Job framework: FIFO queue that respects priority? [message #545526 is a reply to message #545488] |
Thu, 08 July 2010 03:40 |
| Eclipse User |
|
|
|
Hi Randy.
Thanks for your answer. I agree. It seems like the scheduling rules act more
like mutexes.
How do you suggest that I do my own scheduling if I still want to use the
Job framework? Do you suggest that I manually reorder the job queue when I
schedule a new job?
Best regards,
Anders
> It sounds like you've already implemented a scheduling rule that compares
> timestamps. Maybe that rule should first compare the priorities, and then
> only compare timestamps when the priorities are equal.
> It's funny, I just implemented a similar scheduling rule today. I have
> jobs A and B, and I want B to only be scheduled after A has been
> completed. However, I ran into a problem. I'm doing:
>
> A.schedule(8000);
> B.schedule();
>
> But since A is scheduled with a delay, I have problems. Unfortunately, it
> seems like the scheduling rule for B is only consulted if A is currently
> running. But since A was delayed, B gets scheduled and runs before A.
>
> If this is how scheduling rules work, then they aren't really useful for
> scheduling. Actually, aren't they just mutexes? The rules I used for
> jobs A and B aren't symmetric, but the javadoc for isConflicting() says
> that the method must be symmetric, which again sounds more like a mutex.
>
> I'd like to be told otherwise, but it sounds like if you want to guarantee
> the order in which jobs run, you have to do your own scheduling and only
> use ISchedulingRule for avoiding deadlocks.
|
|
|
|
|
| Re: Eclipse Job framework: FIFO queue that respects priority? [message #545801 is a reply to message #545703] |
Fri, 09 July 2010 03:45 |
| Eclipse User |
|
|
|
>
> public boolean isConflicting(ISchedulingRule rule) {
> if (rule == this)
> return true;
> if (rule instanceof MyRule) {
> ...
> return myrule.priority < priority
> && myrule.timstamp < timestamp;
> }
> return false;
> }
>
>
> Something like the above. I'm not sure if "<" is the correct operator.
>
But if I schedule "A B" and B has lower priority than A then they are not
conflicting which means that they can be run at the same time.This is not
allowed in my system.
> Actually, my scenario was only for a pair of jobs, and it only worked if
> the first job is scheduled or running. If I scheduled a 3rd job that
> needed to come between the first 2, I don't think it would work reliably.
>
> Just write your own priority queue and have a single job that services
> that queue. The servicing job would pull a unit of work from the queue
> and run it. When that unit returns, if the queue isn't empty the job can
> just reschedule itself (or you could just loop). When the queue receives
> a new work unit, it would schedule the servicing job (which is a
> singleton).
What would be the advantage of using the Eclipse Job like you describe
compared to using for instance the Executors class, like
Executors#newSingleThreadScheduledExecutor? Don't I loose the advantages of
the Eclipse Job framework when I am not using it's own queue?
Thanks in advance,
Anders
|
|
|
Powered by
FUDForum. Page generated in 0.04635 seconds
Home