[concurrency-interest] do constructors ever involve threading under the covers?
aleksey.shipilev at oracle.com
Wed Oct 3 09:47:51 EDT 2012
On 10/03/2012 05:24 PM, Andy Nuss wrote:
> My code by all appearances is single
> threaded, but I am having strange bugs that on one particular machine
> running vmware, the digest result I am getting (for password hashing)
> appears not to be repeatable.
I don't think this has something to do with concurrency at all. Are you
sure you are reading up all the buffers, flushing and closing the
streams appropriately, etc? What if you have your own dummy
implementation of MessageDigest which only counts the consumed data
size? A test case would be helpful.
> Basically, I am wondering if another thread can execute the body of the
> constructor (or in the construction and use of the OutputStreamWriter,
> within my constructor) that could be causing a bug where memory written
> by the MessageDigest.update() function (triggered within the constructor
> by writing thru OutputStreamWriter) is not seen in the call to digest()
> on the newly created MessageDigest member after the constructor returns.
While the construction you describe here is possible, most MessageDigest
implementations are not threaded, and so both update() and digest() are
getting executed in the single callee context, which means there is no
races. Even if there are digest providers which execute update() and/or
digest() in separate threads, I would be surprised if they are not
enforcing any particular ordering (given concurrent update()-s make
sense for hashing at all).
More information about the Concurrency-interest