What I'm currently trying to do is to use my own thread-safe resolver implementation. Basically I load assemblies on separate threads (just loading shouldn't invoke the resolver, correct?).
But what's also interesting is: Is it safe to access an AssemblyDefinition (for reading only) from multiple threads? I think this really ought to be safe, at least with ReadingMode.Immediate. The lazy initialization pattern used by the Cecil properties seems to be safe - it would be better if the field was marked volatile, but that doesn't make a difference in this case on the current .NET framework implementation. What seems unsafe is the MetadataReader's use of shared state (the context and reading position); but if I use immediate reading mode, the MetadataReader shouldn't be used after the initialization, correct? Jb please correct me if I'm wrong, I don't want to release a decompiler GUI with race conditions (and yes, I do a lot of multithreading to keep the UI responsive). It seems to work fine so far - but then again, it also seems fine with deferred reading mode, which means I'm just (un)lucky and didn't hit the race condition so far. Daniel On 2/15/2011 13:09, Jb Evain wrote: > Let me be perfectly clear : maybe. > > Seriously, I don't think there are many things easily parallelizable > in Cecil without adding lots of locking. > > On Tuesday, February 15, 2011, Simon Cropp <[email protected]> wrote: >> JB >> >> Do you have an plans to make use of multiple threads when reading and >> writing assemblies with cecil? >> >> -- >> -- >> mono-cecil
signature.asc
Description: OpenPGP digital signature
