Don't call back into python during insert (which will leave the set in a broken condi...
authorAkshay Modi <nareshmodi@google.com>
Mon, 11 Jun 2018 17:42:15 +0000 (10:42 -0700)
committerAkshay Modi <nareshmodi@google.com>
Wed, 13 Jun 2018 19:47:02 +0000 (12:47 -0700)
commit50ba6dd3a182c9578bc10cb2a21d7914a1e7bac1
tree9c5e1e66e08cd700709b0041c04657dfda9fa82f
parenta35e9bb050979d045898cadcdc3b0616aa6b62ce
Don't call back into python during insert (which will leave the set in a broken condition if the runtime decides to let another thread run).

Thank you for finding the bug. The watched_variables_ set should not really require a lock since all our functions hold the GIL (verified by looking at the generated SWIG). The reason that there was a concurrent access to the set is that the insert was calling back into python (which might release the GIL and let another thread run, which will also attempt to insert a variable and break the set).

I included the lock to be safe though, since its non-trivial to verify without looking at the generated swig wrappers that the GIL is held.

PiperOrigin-RevId: 200074843
tensorflow/python/eager/pywrap_tfe_src.cc