[Nagios-devel] Multithreaded Nagios Event Loops
Posted: Thu Aug 27, 2009 4:47 pm
Hello Everyone,
So after running through it about thousand times I think I have enough data=
to see what was wrong with my previous approach to multi-threading by spli=
tting the high and low event lists into their own threads.
It turns out there is contention in the macro system, but I think this cont=
ention could be better addressed with less granularity rather than more.
My previous approach placed each read and write to the macro system under c=
ontrol of a mutex, this approach didn't work because the layout of the macr=
o system is as such that ANY access needs to be one thread at a time for th=
e entire time the thread needs access to the macro system.
i.e. It was too granular, so what happened is that one thread would go thro=
ugh and setup the macro array, and the other thread would come in and destr=
oy all that.
My new system is much more simplified, but basically each time a function s=
uch as grab_host_macros is called, we totally lock out access until the thr=
ead is completely done with the macros, and then we release it.
The easiest way to do this would be to utilize a single mutex that is place=
d right before any thread uses the macro system and released as soon as the=
thread is completely done with it.
This will require some serious analysis, but will be worth it
=20
A better solution would of course be to rework the entire macro system so e=
ach thread is working on it's own copy of the entire macro array, but thats=
just not practical for me to do at this time.
So anyways, I'm back on track and if anyone is running a 2x branch of nagio=
s I would really appreciate hearing from you if you have any interest at al=
l in this.
Sincerely,
Steve
NOTICE: This email message is for the sole use of the intended recipient(s=
) and may contain confidential and privileged information. Any unauthorized=
review, use, disclosure or distribution is prohibited. If you are not the =
intended recipient, please contact the sender by reply email and destroy al=
l copies of the original message.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
So after running through it about thousand times I think I have enough data=
to see what was wrong with my previous approach to multi-threading by spli=
tting the high and low event lists into their own threads.
It turns out there is contention in the macro system, but I think this cont=
ention could be better addressed with less granularity rather than more.
My previous approach placed each read and write to the macro system under c=
ontrol of a mutex, this approach didn't work because the layout of the macr=
o system is as such that ANY access needs to be one thread at a time for th=
e entire time the thread needs access to the macro system.
i.e. It was too granular, so what happened is that one thread would go thro=
ugh and setup the macro array, and the other thread would come in and destr=
oy all that.
My new system is much more simplified, but basically each time a function s=
uch as grab_host_macros is called, we totally lock out access until the thr=
ead is completely done with the macros, and then we release it.
The easiest way to do this would be to utilize a single mutex that is place=
d right before any thread uses the macro system and released as soon as the=
thread is completely done with it.
This will require some serious analysis, but will be worth it
=20A better solution would of course be to rework the entire macro system so e=
ach thread is working on it's own copy of the entire macro array, but thats=
just not practical for me to do at this time.
So anyways, I'm back on track and if anyone is running a 2x branch of nagio=
s I would really appreciate hearing from you if you have any interest at al=
l in this.
Sincerely,
Steve
NOTICE: This email message is for the sole use of the intended recipient(s=
) and may contain confidential and privileged information. Any unauthorized=
review, use, disclosure or distribution is prohibited. If you are not the =
intended recipient, please contact the sender by reply email and destroy al=
l copies of the original message.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]