The deadlock detection interval was not always a feature of IDMS.
Somewhere in its post 10.0 life, someone at Cullinet had done some
studies and determined that IDMS spends some major time executing the
deadlock detection code and walking lock chains. This deadlock detection
interval was then developed. My personal opinion is, they didn't
develop things lightly, and there must have been some major push for it,
possibly from a customer, like BT. Although I am wildly guessing here.
I do know that at one time it was thought to be a great idea. As far as
delaying the termination of a task that's deadlocked anyway by some
seconds, I dont think it's a major deal. You will save CPU cycles
though. How much, I've heard, but the percentage was so large that I
would not say it out loud. Try it and see. If all of your tasks,
except the exception, finish in under a minute, I would try it,
benchmark it before and after. Benchmark the tasks, if you can, instead
of just all of IDMS. Unfortunately you'll have to turn task statistics
on, which will increase your overhead and CPU consumption, so be weary.
Maybe just a measure for all of IDMS on like days, before and after to
see if there's promise, to start with.
Lutz Petzold
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
*****JuliusBaer Disclaimer***** This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL:
http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: Deadlock Detection Interval
"The deadlock detection interval was not always a feature of IDMS.
Somewhere in its post 10.0 life, someone at Cullinet had done some
studies and determined that IDMS spends some major time executing the
deadlock detection code and walking lock chains. This deadlock detection
interval was then developed. My personal opinion is, they didn't
develop things lightly, and there must have been some major push for it,
possibly from a customer, like BT. Although I am wildly guessing here.
I do know that at one time it was thought to be a great idea. As far as
delaying the termination of a task that's deadlocked anyway by some
seconds, I dont think it's a major deal. You will save CPU cycles
though. How much, I've heard, but the percentage was so large that I
would not say it out loud. Try it and see. If all of your tasks,
except the exception, finish in under a minute, I would try it,
benchmark it before and after. Benchmark the tasks, if you can, instead
of just all of IDMS. Unfortunately you'll have to turn task statistics
on, which will increase your overhead and CPU consumption, so be weary.
Maybe just a measure for all of IDMS on like days, before and after to
see if there's promise, to start with.
Lutz Petzold
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: Deadlock Detection Interval
"Chris,
I can't address the benchmark aspect of deadlock detection overhead, I
simply don't have that kind of information available, but I would like to
point out that when a deadlock occurs, and it hasn't been detected, all the
locks held by the task that will eventually go away, could be keeping others
from completing there assigned mission. So, if you change the deadlock
interval from 1, to say 5, seconds, then for the 5 seconds that the deadlock
task remains in the system, all locks held by that task can keep other tasks
from completing. Now, since we are referring to a deadlocked task, we know
that the other tasks that are waiting on the deadlocked task are not
involved in the deadlock, allowing them to finish won't clear up the
deadlock, so why hold them up if they can complete. Furthermore, while these
tasks are waiting on locks held by the deadlocked task, they, too, could be
holding locks which cause other tasks to wait.
Does this all make sense?
So, the bottom line is, yes, you can increase the deadlock detection
interval. Yes, you are averaging only one deadlock every hour. But, what
impact would there be if you did increase the interval?
As long as you go into this type of a change knowing what could happen, then
you can make an educated decision as to whether or not to leave the interval
longer or go back to a shorter interval.
Also keep in mind that task resources are involved here as well. Single
threaded programs, storage, ENQUEUEs, etc, are all held until the deadlocked
task is aborted. They, too, can be a bottleneck as long as the deadlocked
task remains in the system.
Hope this helps.
Chuck