Re: [DynInst_API:] Concurrent calls to getInsns

[Barton Miller <bart@xxxxxxxxxxx>]

Thomas,

Note that Bill is busily working on heavily multi-threading parts of the Dyninst tookits, to improve parse and analysis time.  Some of that is already in place, but lots more to come.

--bart

On 7/24/2017 1:28 PM, Thomas Dullien wrote:

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 <bill@xxxxxxxxxxx> 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 <dyninst-api-bounces@xxxxxxxxedu> on behalf of Thomas Dullien <thomasdullien@xxxxxxxxxx>
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
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api