I don't understand Synclock.

[Jeff Stewart]

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!

 

[Richard Myers]

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]

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.

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

 

[Rob Teixeira]

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

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?"

 

[Richard Myers]

Hi Jeff

The lock is just a token;this can be anything;when you create a lock you define a token;if the token
is used/in possesion of another thread then it blocks other threads from taking ownership of the
token.

If your talking about the really low level implementation of this feature then im not entirely sure
as one of the great things about OOP is its' black box nature.

I would assume the "token" is just given a memory space as usual and to which a secondary pointer
is appended under the covers. This pointer would then poiint at the owner of the token or be null.
If a thread tries to access a token which has a pointer that is not null or pointing to itself then
it is blocked? If the pointer is free; the thread regsiters itself such that the pointer address
points back to the registering thread so if other threads try to gain access they are blocked.

When then thread is done (EndSynclock) it releases the token by setting the pointer to null so other
threads can have a crack at it. In this way the synch lock is kinda like a box. Inside the box is
whatever Synchlock is protecting plus a pointer to whoever owns the box at that particular moment.

Chances are this is completely wrong, its an interesting question but i haven't really thought about
the precise mechanism it uses- Im an applications developer not a systems developer so i prefer to
spend more time listening to the customer than worrying about the way windows/clr shunts its bits
and bytes around. I suppose i should know but the truth is Im not absolutely certain?

Richard

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?"
sure