camera2: Reduce metadata lock contention
Before this change, the native methods for metadata
access were static and synchronized, which meant that
all calls would contend for the same class lock.
This isn't actually necessary since the only true global
being accessed in native metadata is the VendorTagCache,
that is already protected by an internal lock in the native
code.
We do however, need to have the java methods which involve
reading and writing to metadata be synchronized since even though
CaptureRequest and CaptureResult apis are read only,
CaptureRequest.Builder has both getters and setters. It also
has an internal CameraMetadataNative object, on which the getters and
setters can be called from different threads - even though we don't
officially say in the API spec that it is valid to do that.
A ReadWrite lock hasn't been used since in performance profiling there
doesn't seem to be a noticeable difference between using it and regular
synchronization with GCA. A ReadWrite lock would need explicit lock() and
unlock() calls, which may be more error prone.
Bug: 336882162
Flag: EXEMPT, 'synchronized' keyword being deleted from JNI calls can't
be flagged
Test: GCA shows no global lock contention for metadata access
Test: GCA - basic validity
Test: Camera CTS
Change-Id: I22efb13c835388d4bb41a7a67e46b0215ef29e55
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
1 file changed