Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 231
  • Last Modified:

Does synclock apply to code called from within block

In this scenario

=======================
dim someObject as new object

SyncLock someObject

    Dim exe as new Doer_Class
    exe.DoMethod()              

End SyncLock
=======================

Is all the code that is executed by the block, including the code within DoMethod (and any other methods that might be called by DoMethod), protected by the SyncLock?

0
codequest
Asked:
codequest
  • 3
  • 3
1 Solution
 
VultenCommented:
Depends on what you mean by "protected". No other thread will be able to access the Code-snippet

---
 Dim exe as new Doer_Class
 exe.DoMethod()    
---

as long as another thread is running it.

So in that sence it will be protected. However if the "exe"-object uses any Shared resources in the Doer_Class or elsewere, those will not be protected.

So in this case, since you create a new object (exe) within a SyncLock, that object will surely be protected as long as it does not use Shared Resources.

0
 
codequestAuthor Commented:
Vulten: Thanks for your response.  Since this is new territory for me, I'd appreciate any further clarification you could offer on the following.

Since asking the question I've gotten more concrete.   I've reorganized my code so that a bunch of dataset manipulations can only be accessed through DoMethod.

---
dim varCmd as new DataSetCommandStructure

with varCmd
(fill varCmd variables)
end with

Dim exe as new Doer_Class
dim obj as new object
synclock obj
exe.DoMethod(varCmd)    
end synclock
---

In this case, there are lots of method calls under DoMethod, and none of them can be called from anywhere else.  So the in the concrete example, the question is, will all that code under DoMethod be "protected" in the sense that only one thread can run it at a time, because of the synclock around DoMethod?

I think your answer said "yes", but since my understanding of this stuff is not that great, I'd appreciate any further confirmation that you could offer.

Thanks!

PS:  

I think also I'm hazy on this because A) I'm not that familiar with object terminology, and B) I'm confusing the idea of synclock, which prevents threads from running through blocks, with "locks" on database files, records and so-on.

I think that in your message you're correctly using 1) object to mean "some code", and that "protected" to mean "only one thread at a time"...my brain keeps trying to translate that into 2) "some data", and "can't be changed"....which isn't right....I believe "1)" is right.




0
 
VultenCommented:
Class vs. Object

See the Class as a mould from which you create your Objects. Each time you use your mould you create a new Object. Hence from one Class you can create as many Objects as you like with, for example “Dim newObject as New ArrayList” or “Dim newObject As ArrayList = New ArrayList” (the same thing)

Having said that, you might already have guessed that even though you have “confined” a method inside a Class, it will still be available from within every single Object created from this Class. So, if each of your Threads have created ONE Object of their own from you Class (your mould) each of those Threads will have their own “version” of the Class running in memory simultaneously (an Object created from your Class)

In your First Example
dim someObject as new object

SyncLock someObject

    Dim exe as new Doer_Class
    exe.DoMethod()              

End SyncLock

(I hope you don’t let every Thread create a “dim someObject as new object” Put it as a Private variable just under your Class Name (making it globally accessible from within your class… NOT inside the actual Method in the Class)

Example:

Public Class SomeClass
   Private m_SomeObject as new Object ‘ To confuse you further…;-) Object in this case is a Class… In VB 6 it was called Variant (which doesn’t exist anymore)

   Public Sub ThreadEntry
      SyncLock m_SomeObject
      Dim exe as New Doer_Class
      Exe.DoMethod
      End SyncLock
   End Sub
End Class

You created your exe Object from your Doer_Class mould INSIDE the SyncLock itself. Doing so will prevent any other Thread from creating their own Object from the Doer_Class until the first Thread has finished. Provided that you don’t create any other Objects from the Doer_Class somewhere else in your application… this is as safe as it gets.

The only this you have to make sure is that your Class (Doer_Class) does not have anything declared as SHARED, since Shared means that EVERY single Object created from your Doer_Class will share this Variable with each other. So even if you create ten different separate Objects from your Class, which will, as I said before, live their own separate life in memory they will ALL SHARE any Variable declared as Shared.

If for example in your case your Doer_Class have a “Shared myConnection As DbConnection” to Connect to your database you have to make sure that you only have One Object created at a time if myConnection must remain Protected.

So once again, if you create an Object from the Doer_Class from within a SyncLock and you are sure that no other Object from that Class will be created outside your method… this will be Protected and quite safe even if it has Shared Variables.

BUT.. in your second Example
Dim exe as new Doer_Class
dim obj as new object
synclock obj
exe.DoMethod(varCmd)    
end synclock

You create an object outside the SyncLock. So every thread that comes here will have their own version of your code (remember… the Class is the Mould used to create Separate Objects in memory)… This is normally not an issue… but if you feel insecure of Classes and Object maybe you should avoid it for the time being

Then it looks like you create an obj as new object (inside your Method???? I hope NOT) man… that’s like providing each Thread their OWN DOOR… this will NOT work since the Lock is on a Specific Object… And in this case you let EVERY Thread Create their own SyncLock, meaning that that every time a new Thread Comes along a NEW Door will be available… When the Thread Enters it locks that new door shut  (from the inside of the method (and opens it when it exits)… But since the next thread that comes along  get a brand new door.. it really doesn’t matter if another door is locket or not. It can still enter.

Wow quite an essay this… hope it helps… the short version is

Public Class SomeClass
   Private m_SomeObject as new Object

   Public Sub ThreadEntry
      SyncLock m_SomeObject
      Dim exe as New Doer_Class
      Exe.DoMethod
      End SyncLock
   End Sub
End Class

m_SomeObject MUST be used by every thread that enters… So place it with a Global Scope.

Just to be certain… Create your object Inside your SyncLock and use it Inside your SyncLock

Good Luck!
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
codequestAuthor Commented:
Way cool.  Very helpful.  I think that wraps it up.  Thanks for taking the time.  If I need more clarification while implementing, I'll post other, more specific questions.  But I think this nails it.

Grazie!

0
 
VultenCommented:
Prego!

And don't forget to wrap this question up too ;-)

/Vulten
0
 
codequestAuthor Commented:
Definutely.  You'd earned the points on the first response.

I probably am going to post another question, but may not get to it for a few days.  If I do and you see it, I hope you can respond.

Cheers!
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

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