Basically, this creates a Synchronization object. If you type Synclock
MyObject, MyObject becomes the key (probably creates something akin to a
Mutex internally).
Think of this as a gas station bathroom. The bathroom is the code inside the
Synclock block. Synclock is the station attendant, and the sync object you
provide is the key. The customers wanting to use the bathroom are the
different threads. The threads get to the synclock statement which is like
asking the attendant for the key, but if someone else already has the key,
the new customer has to wait to get into the bathroom until the customer who
has the key releases it back to the attendant - which is what happens when
the first thread reaches the End Synclock statement.
I've never actually researched what it "really" does internally, but my
guess is that it creates a sync wait object, like a Mutex. Any thread
executing the synclock statement is really trying to get exclusive access to
the wait object, and if the wait object has a previous ref count, the new
thread either spins until it can get the exclusive access, or it goes into a
wait state until the wait object signals that it's free. Either way, the end
result is pretty much the same - only one thread at a time can have
exclusive access to the wait object.
-Rob Teixeira
"Jeff Stewart" <ja*@micronovatech.com> wrote in message
news:1099959308.PUM15gOliewqRbiF6R5yFg@teranews...
:)
OK, but what decisions are made, internally, regarding the "lock"? What
is the mechanism by which the lock, or locked "thing" can affect whether
another thread can or cannot obtain the lock? When a lock is obtained by
one thread, how does a second thread reach the conclusion that a thread
other than itself "has the lock?"
--
Jeff S.
"Richard Myers" <fa**@address.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... Hi Jeff
Ref are memory locations on the heap. They are called ref types becuase
unlike value types such as
simple primitives such integers,booleans,strucutres etc they are not
assigned space on the Stack but
are merely "referred" to by pointer on the stack to some location on the
heap.
SyncLocking in a very basic sense just protects an area in
memory/stack/heap such that only the
thread that has the lock has access to that memory space.
I think of SyncLocks as basically a top down one at a time funnel or
queue. Think of it as a
monogamous relationship - one at a time please - approach to
class useage... as opposed to non thread safe - dirty old skank - code
that freely lets every man
and his dog have a crack at it as and when it pleases.
The latter approach leading to all forms of vile corruption.
hth
Richard
"Jeff Stewart" <ja*@micronovatech.com> wrote in message
news:1099953916.Fbdfx3mDVKhHNq5TeS3SAw@teranews... Specifically, I don't understand the parameter that Synclock accepts.
How
is a reference type a lockable entity? What -is- a reference type? Is
it a
number? Is it a value at a specific memory location? Does synclocking
a reference type put an entry in a catalog somewhere in the system, and
it's
removed on the "end synclock" statement? Are there any guidelines for
creating synclock objects?
I've found a surprisingly small amount of information on the web.
Everybody
just seems to know, or doesn't care, how Synclock works internally --
they
just create an Object and use it as Synclock's parameter. This is
driving
me nuts! :)
--
Jeff S.