Hi -
Related to RHBZ1325363, presenting for your review, a series of
patches for multithreading pmNewContext and its client pmmgr.
Following up from brolley/lberk reviews-in-progress, a few more
patches on the pcpfans.git fche/multithread branch:
commit 412a4e4120468afd176475826258251f3c158ecc
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Thu Apr 14 15:30:31 2016 -0400
multithreaded pmNewContext: tweak locks and errors
Eagle-eyed brolley found a few places where PM_UNLOCKs mismatched
PM_LOCKs in the new code. Fixed those. In addition, tweaked
pmReconnectContext, pmDupContext, pmDestroyContext, pmUseContext
to more vigorously detect & reject FREE/INIT state contexts.
commit ae0d529079a791db58390099b9debe3c15808de1
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Tue Apr 12 08:26:34 2016 -0400
pmmgr: tweak threading and verbosity
The recent pmcd-search multithreading work spun off threads up to a
calculated or configured limit, where that limit was independent of
the amount of work available for the threads. This could waste time &
momentary memory. We now limit multithreading to the actual number of
input work items.
While in the vicitinity, tweak message-verbosity so that pmmgr -v
prints a good bare-essential level of information (remote pmcds
found, daemons started), which is a good default. -v -v prints
much more detail.
commit ad40e392f0556efe1221ac101734b2269a6508f3
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Mon Apr 11 10:27:14 2016 -0400
pmNewContext multithreading: defer derived-metric initialization
lberk reported that a $PCP_DERIVED_CONFIG-laden pcp app segv's due to
__dmopencontext() running general pmapi functions on the being_initialized
context structure. We defer this until after the context[] slot is set,
marking the beginning of its pmapi usability.
_______________________________________________
pcp mailing list
pcp@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/pcp