Unsolved
This post is more than 5 years old
2 Posts
0
2474
November 30th, 2009 04:00
Thread safety in Centera SDK
Question 1:
I read in the EMC Programmers Guide that all EMC operations except stream operations are thread safe.
==> is it correct that if we create 1 pool per thread (just at the initialization of each threading function), that we will never need any mutexes/serializations in our code?
Question 2:
Furthermore I checked and saw that several Clip operations need exclusive access to the Clip in memory.
==> Does the Clip access means that only 1 function in our program at a time can access the same clip at a time? Even if the same clip is opened twice in seperate threads? Or is it the Clip-per-pool a safe way to go?
Thanks,
Steven
No Events found!
mikehorgan
47 Posts
0
December 4th, 2009 13:00
Hello Goofy (uh, I mean Steven) -
Your best bet for pool management is to create a single FPPool instance and share it across all of your threads. This will result in very efficient use/reuse of socket connections between the SDK and Centera, without requiring any locking or mutexes in your code. If you were to open an FPPool instance for each thread you will end up with lots of "connected but idle" sockets between your program and the Centera, and (depending on load and cluster configuration) may bump into the hard limit of 100 open sockets per access node in CentraStar.
"Exclusive clip access" means exclusive rights to an FPClip instance in your program, not global exclusion for the c-clip object stored in Centera. A Centera c-clip can be opened any number of times (through repeated calls to FPClip_Open) across any number of threads simultaneously without issue; since Centera is a fixed-content storage device there isn't (much) of a "update race condition" issue (except in the case of the mutable metadata features, namely event-based retention and litigation hold).
Best of luck with your Centera coding!
Mike Horgan
g00fy2
2 Posts
0
December 7th, 2009 01:00
gstuartemc
2 Intern
•
417 Posts
0
December 7th, 2009 03:00
I am not sure what you mean by "serialize the data streaming".
There are standard API calls that will write the full contents of a file or a memory buffer onto a tag as a distinct object, so you do not require to do anything special here (other than populate the file / buffer with your data and ensure the application can access it).
On reading content back, you would need to ensure that your output file / buffer is not being written to by other applications.
If you are making use of the Generic Streams framework then you write / read the data using callbacks that are registered with the Generic Stream. These callbacks would populate / retrieve the content object's data block by block (typically 16K) via a reusable buffer. Your application would read / write these blocks from your object (which, again, you would need to ensure was not being written to by other applications).