[libcamera-devel] [RFC PATCH 5/6] android: camera_device: Add thread safety annotation

Hirokazu Honda hiroh at chromium.org
Tue Nov 30 13:13:00 CET 2021


Hi Umang,

On Tue, Nov 30, 2021 at 3:28 PM Umang Jain <umang.jain at ideasonboard.com> wrote:
>
> Hi Hiro,
>
> On 11/29/21 5:08 PM, Hirokazu Honda wrote:
>
> <snip>
> >
> >>
> >> Well, the document currently states that ACQUIRED_AFTER is currently
> >> un-implemented.
> >>
> > Oh I don't know that. What document do you refer?
> > I couldnm't find it in
> > https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#acquired-before-acquired-after.
>
>
> https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#acquired-before-and-acquired-after-are-currently-unimplemented
>

Thanks! I definitely missed it.
-Hiro
> >
> >> Secondly, I don't think we enforce a design interaction between the two
> >> mutexes currently, that requires this macro. For e.g.
> >> completeDescriptor() on a requestcomplete() path, will acquire
> >> descriptorsMutex_ irrespective of acquiring stateMutex_. Is there any
> >> strong reasoning I am missing which led to use of ACQUIRED_AFTER for
> >> descriptorsMutex_?
> >>
> > No strong reason. I think it is nicer to clarify the order.
> >
> >  From the code, I think this is the current order used in code.
>
>
> Makes sense.
>
> >
> > Thanks,
> > -Hiro
> >>> +     std::queue<std::unique_ptr<Camera3RequestDescriptor>> descriptors_ GUARDED_BY(descriptorsMutex_);
> >>
> >> This is becoming a bit harder to read (not your fault, probably mine). I
> >> should spend some time tinkering on naming these members/classes.
> >>
> >>>        std::string maker_;
> >>>        std::string model_;


More information about the libcamera-devel mailing list