Hey there, ok cool :-) -- I think the statement "assume thread-unsafe for the moment" is already quite helpful, fixed my code accordingly. I guess I will just wait for new releases & keep my eyes peeled for changes in that area? :)
Cheers, Thomas On Mon, Jul 24, 2017 at 7:40 PM, Bill Williams <[email protected]> wrote: > This is an area with some active work occurring. However, it is best to > assume that interfaces are thread-unsafe in the current releases and > require external locking. > > If you need guidance on how best to manage concurrent access to Dyninst > data in the meantime, let us know; the proper strategy depends to some > extent on your use case. > > --bw > > ________________________________________ > From: Dyninst-api <[email protected]> on behalf of Thomas > Dullien <[email protected]> > Sent: Monday, July 24, 2017 5:16 AM > To: dyninst-api > Subject: [DynInst_API:] Concurrent calls to getInsns > > Hey there, > > I am observing data races and inconsistent results when multiple > threads run through the following code: > > Dyninst::ParseAPI::Block::Insns block_instructions; > block->getInsns(block_instructions); > for (const auto& instruction : block_instructions) { .... } > > Are Dyninst functions thread-unsafe by default, or what is the best way of > finding out which ones are safe and which ones aren't ? :-) > > Cheers, > Thomas > PS: Thanks for the awesome tool ! :) >
_______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
