Method get

src/IECorePython/LRUCacheBinding.cpp:113–146

		}

		object get( const object &key )
		{
			// we must hold the GIL when entering LRUCache<object, object>::get()
			// or any other of our base class' methods, because they manipulate
			// boost::python::objects, which in turn use the python api. in addition,
			// LRUCacheGetter enters python, giving us another reason to need the
			// GIL. things are complicated slightly by the fact that the python code
			// executed by LRUCacheGetter may release the GIL, either explicitly or
			// because the interpreter does that from time to time anyway. this can
			// allow another thread to make a call to get(), potentially with the same
			// key as was passed to the current call. this would lead to deadlock -
			// the first call doing the caching waits for the GIL to continue,
			// and the second call holds the GIL and waits for the caching to be
			// complete.
			//
			// the code below avoids this, by ensuring only one thread can be in
			// LRUCache<object, object>::get(), at any given time, and by releasing
			// the GIL while it waits for m_getMutex. this allows the first thread
			// to finish caching (because it can reacquire the GIL), at which point
			// it will release m_getMutex, allowing the second thread to go about
			// its business.
			//
			// while this serialisation may seem inefficient, it's less of a big
			// deal because all python execution is serialised anyway.
			//
			// see test/IECore/LRUCache.py, in particular testYieldGILInGetter().

			std::unique_lock<Mutex> lock( m_getMutex, std::defer_lock );
			{
				IECorePython::ScopedGILRelease gilRelease;
				lock.lock();
			}
			return LRUCache<object, object>::get( key );
		}

	private :