lazyTypes.h was also modified. HAVE_STD_THREAD macros were removed from cllazyfile library *.cc and *.h since classes sc_thread and sc_mutex internally handles the macros.
This acts like a wrapper to some of the thread functionalities (like get_id()) which is being used in stepcode. If the compiler does not supports thread functionalities then this class provides dummy types and functionalities.
Adding the Remove( SDAI_ptr ) API to SDAI__set made SDAI_Application_instance__set a candidate for inheriting common logic from SDAI__set.
Note: This class was already made thread safe in one of the previous commits. This commit only removes the now apparent duplicate code.
The semantics of this function would be similar to SDAI__set::Remove( SDAI__set::Index( SDAI_ptr ) ). The only difference would be that in the new function both the operations are done under a single lock.
Wherever the old Remove( Index( SDAI_ptr ) ) code snippet was found, it was replaced by the new Remove( SDAI_ptr ) function.
Variables of class InstMgr were being iterated upon in class STEPfile through the variables _instances (including its get function instances()) and _headerInstances. The mtx defined in InstMgr was invoked to make them safe.
The SDAI_Application_instance * GetApplication_instance( MgrNode * ) and MgrNode * FindFileId( int ) methods of class InstMgr were often being used together in the class STEPfile. Hence a special function was created in class InstMgr of the form SDAI_Application_instance * GetApplication_instanceFromFileId( int ) which would take care of locking and consistency issues. This function was then used in STEPfile.
_headerId is a counter used in STEPfile class. Its value can change in ReadHeader and ReadExchangeFile methods. Hence a mutex was introduced in order to protect it.
Originally For the second pass a new istream (in2) was being created and the .step file was being opened again. This was prevented by directing the original istream (in) to the beggining of the .step file.
In the original function a static string was being used. The dependency on the static string was removed by passing a string as a parameter from the caller to callee, so that the function could operate without worrying about thread safety.
The function name change mimics the change in the semantics of the function.
A mutex was introduced to proctect the counter and the pointer to clists.
The insert and remove functions were tricky to make thread safe as clists may or may-not have been initialized. Hand-over-hand locking was used.
Like the classes before, used sharedMtxP to protect the EntNode list whenver it was being iterated upon.
Also added a public mutex to protect the public next pointer. Resposibilty of using it will fall to the class which is using next pointer (ComplexCollect)
Under the assumptions that an EntList object cannot be inserted in between two EntList objects and cannot be removed from a list of EntList objects, making this class thread safe became trivially easy.
One mutex per EntList object was introduced to support appending of EntList objects. As this feature would be used by its subclass (MultList)
The assumption used was that STEPcomplex class wont in future provide an API through which threads can remove / insert a STEPcomplex node.
Three already declared mutexes were used in for this purpose:
(1) A recursive mutex for each STEPcomplex node (borrowed from the superclass SDAI_Application_instance)
(2) A recursive mutex belonging to AttrDescriptorList class (originally defined in SingleLinkList class)
(3) A recursive shared mutex belonging to EntNode class.
The fixed order between the locks was: (2) > (1). (3) was independent.
The STEPattributeList data was being iterated and modiefied by the SDAI_Application_instance class without invoking the mutex of the STEPattribute class. This was fixed in this commit.
