When I first did this, the locks were for disallowing coprocessor registration
while the upcall chain is being processed. So CopyOnWrite would be fine for
that.
CPHost locks shouldn't be used to serialize anything else. If that is
happening, it's by accident / a bug.
- Andy
--- On Tue, 3/1/11, Ryan Rawson <[email protected]> wrote:
> From: Ryan Rawson <[email protected]>
> Subject: Re: Coprocessor tax?
> To: [email protected]
> Cc: "Gary Helmling" <[email protected]>
> Date: Tuesday, March 1, 2011, 12:08 PM
>
> My own profiling shows that a read write lock can be up to 3-6% of the
> CPU budget in our put/get query path. Adding another one if not
> necessary would probably not be good.
>
> In fact in the region coprocessor the only thing the write lock is
> used for is the preClose and postClose, but looking in the
> implementation of those methods I don't really get why this is
> necessary. The write lock ensures single thread access, but there is
> nothing that prevents other threads from calling other methods AFTER
> the postClose?
>
> -ryan
>
> On Tue, Mar 1, 2011 at 12:02 PM, Gary Helmling <[email protected]>
> wrote:
> > All the CoprocessorHost invocations should be wrapped
> > in "if (cpHost != null)". We could just added an extra check for
> > whether any coprocessors are loaded -- "if (cpHost != null &&
> > cpHost.isActive())", something like that?
> > Or the CoprocessorHost methods could do this checking internally.
