|Project Name||STEP Libraries: Improving Thread Safety and Performance|
|Project Student||Pulkit Mittal|
- Thread Safety in cllazyfile Status: Doing
- Thread Safety in clstepcore Status: Not Started
- Thread Safety in cleditor Status: Not Started
- Thread Safety in cldai Status: Not Started
- Introduce multithreading cllazyfile Status: Not Started
In this section I will list down all the single threaded performance optimizations which are done in the GSOC period.
17 May (Sat):
- Figured out various functionalities in cllazyfile step library which should be made thread safe.
- Opening multiple files in parallel.
- (lazy) loading separate SDAI_Application_instance in parallel.
- Reading the forward / backward references of instances in parallel.
- Finding instances belonging to same / different types in parallel.
- Initializing / Setting the registry in parallel.
- Registering Data Sections in parallel
- Strategizing how the various features will be added into the code. Firstly a test will be created to note the existance of thread safety for the above features. If the test fail then appropriate coding will be done
18 May (Sun):
- A test was created in lazy_thread_safety_test.cc file, to check the concurrent read safety of getFwdRefs() and getRevRefs() and expectedly it failed.
- Note: to run the test, the CMakeFiles: cmake/SC_CXX_schema_macros.cmake & src/cllazyfile/CMakeLists.txt were slightly messed up.
19 May (Mon):
- Introduced getFwdRefsSafely and getRevRefsSafely which are thread safe. The thread safety test in lazy_thread_safety_test.cc passed. Submitted code through git in a branch called hj/cllazyfile-thread-safety.
- Discussed with mentor about the importance order of functionalities mentioned above. Hence will be covering the functionalities in the following order 3(done)>4>2>1>6
20-21 May (Tue, Wed):
- Noticed that getFwdRefsSafely and getRevRefsSafely are consume memory each time they are called (as separate clones are made for each invocation). (Blame the use of Judy Structure) The memory is freed only when destructor of lazyInstMgr is called. One way around this problem was to let the user call a function (say) returnFwdRefsSafely which would release the space related to a clone. Hence, I spent 2 days trying to modify the original judy code so that it allows closure of clones. But as I was not able to get a breakthrough, I have left this task for later.
22 May (Thu):
- Created a test to check the thread safety of getInstances (i.e. finding instances belonging a specific type). As expected the test failed when the number of invocations were very high. This is because getInstances internally uses find operation which is not thread safe.
23 May (Fri):
- Added the thread-safe getInstancesSafely and countInstancesSafely. Also submitted the code in github.
24 May (Sat):