• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 852
  • Last Modified:

How Synclock and Cache Work Together

Suppose I build a datatable, and fill it.
And that I have methods for putting the table in cache (Application Cache or Session cache or "Cache" cache) and getting it out again.

And I put it in cache.  And then I do this:

dim dt as datatable = GetTableFromCache("MyTable")
synclock dt
(do things to dt)
synclock end
PutTableInCache(dt)

What I'm trying to figure out is:
A)  is the dt just a reference to the table, which is actually in cache?
B)  is it necessary to put it back, or have the changes to dt already been made to the table in cache (since dt is just a reference)
C)  is the table in cache safe from any changes by any other thread during this operation, or could a change slip in between the "dim dt" and the "synclock dt".

Any guidance on this would be appreciated.

Thanks!
0
codequest
Asked:
codequest
1 Solution
 
naveenkohliCommented:
1. Yes it is reference to that object on heap. Any changes made to it will get reflected.
2. You don't have to put it back but it would not hurt to do it. Especially if you are using sliding expiration policy for cach expiration then adding it back will make sure that expiration time has restarted.
3. Yes, there is a chance somebody can grab the table before you acquire the sync lock. I would suggest to put the accessor methods (get/set) for this table to be encapsulated in their own methods and each method provides synchronized access to the table.

something like..

gettable()
{
   DataTable dt = null;
   lock(myLock)
   {
      dt = cache.table;
   }
   return dt;
}

settable(dt)
{
  lock(mylock)
  {
     cache,table = dt;
  }
}
0
 
codequestAuthor Commented:
Thanks.  There's a lot to learn about synclock, this was a good start.

Part of what I'm learning is

A) recognizing the differences between code blocks (which can include nested calls), code paths (which are strings of blocks, which may cut into a heirarchy of nested calls), and threads (which are actual operations of paths, which then hit blocks.)

B) understanding that synclocks only lock code blocks, not data elements.  They just keep other threads out of the block, but if there's some other path to get to the data element in (or nested under) the block, then that data element won't be protected by the lock.




0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now