SyncLock

[fred]

If I have multiple threads running a Sub as below then a number of threads
can be held up at the SyncLock. When it becomes free which thread goes
first. Is it just by chance which thread goes first or do the threads queue
in a FIFO or perhaps a LIFO bases.

Thanks
Fred
Sub SomeWork()
SyncLock Me.GetType
...Code here
End SyncLock
End Sub

[CJ Taylor]

It uses a FIFO Queue.
"fred" <So***@NoSpam.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

If I have multiple threads running a Sub as below then a number of threads
can be held up at the SyncLock. When it becomes free which thread goes
first. Is it just by chance which thread goes first or do the threads queue in a FIFO or perhaps a LIFO bases.

Thanks
Fred
Sub SomeWork()
SyncLock Me.GetType
...Code here
End SyncLock
End Sub

[Jay B. Harlow [MVP - Outlook]]

Fred,
I don't have links handy, however I have seen numerous recommendations that
you should NOT use Me.GetType to lock on, that instead you should create an
explicit "padlock" variable. The biggest reason being is you may lock on
Me.GetType for one reason, while another section of code my attempt to lock
on Me.GetType for a different reason and you actually introduced a deadlock!
Also Me.GetType is not instance sensitive. All instances of the class will
block on the type, which most of the time you only need to lock on the class
instance...

The easiest way to create a "padlock" is a new object, literally "new
object"

private readonly m_padlock As New Object()

Sub SomeWork()
SyncLock m_padlock
...Code here
End SyncLock
End Sub
You can make m_padlock Shared if you need it to be across instances, however
IMHO most of the time you do not need Shared padlocks, as you want each
instance of a class to be able to run on its own thread.

Hope this helps
Jay

"fred" <So***@NoSpam.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... If I have multiple threads running a Sub as below then a number of threads
can be held up at the SyncLock. When it becomes free which thread goes
first. Is it just by chance which thread goes first or do the threads queue in a FIFO or perhaps a LIFO bases.

Thanks
Fred
Sub SomeWork()
SyncLock Me.GetType
...Code here
End SyncLock
End Sub

[Fred]

Thanks for the advice Jay. I will take your advice but I am not sure I
understand why.

Am I right in thinking that it can only be a problem if the program running
between the SyncLock and End SyncLock has a possibility of recalling the
"SomeWork" sub or running another SyncLock Me.GetType somewhere.

Thanks
Fred

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:Of*************@tk2msftngp13.phx.gbl...

Fred,
I don't have links handy, however I have seen numerous recommendations that you should NOT use Me.GetType to lock on, that instead you should create an explicit "padlock" variable. The biggest reason being is you may lock on
Me.GetType for one reason, while another section of code my attempt to lock on Me.GetType for a different reason and you actually introduced a deadlock! Also Me.GetType is not instance sensitive. All instances of the class will
block on the type, which most of the time you only need to lock on the class instance...

The easiest way to create a "padlock" is a new object, literally "new
object"

private readonly m_padlock As New Object()

Sub SomeWork()
SyncLock m_padlock
...Code here
End SyncLock
End Sub
You can make m_padlock Shared if you need it to be across instances,

however IMHO most of the time you do not need Shared padlocks, as you want each
instance of a class to be able to run on its own thread.

Hope this helps
Jay

"fred" <So***@NoSpam.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

If I have multiple threads running a Sub as below then a number of threads can be held up at the SyncLock. When it becomes free which thread goes
first. Is it just by chance which thread goes first or do the threads

queue

in a FIFO or perhaps a LIFO bases.

Thanks
Fred
Sub SomeWork()
SyncLock Me.GetType
...Code here
End SyncLock
End Sub

[Jay B. Harlow [MVP - Outlook]]

Fred,

Am I right in thinking that it can only be a problem if the program running between the SyncLock and End SyncLock has a possibility of recalling the
"SomeWork" sub or running another SyncLock Me.GetType somewhere. No!

SyncLock is NOT needed if the same thread can call the SomeWork method while
the SomeWork method is executing, as that is simple recursion.

SyncLock is needed if two threads can call SomeWork for the same object, at
the same time, if SomeWork modifies that object.

SyncLock is NOT needed if SomeWork can be called for different objects and
you are encapsulating your data within an object.

SyncLock is needed when using "global" variables (Module, Shared Class, or
Shared Structure variables).

SyncLock is also needed if two threads both are calling methods, properties
or using fields on the same object, at the same time. Normally its better to
encapsulate the SyncLock internal to the object itself.

Of course there are exceptions to the above broad rules, and there may be
better locking mechanisms in System.Threading depending on what you are
trying to accomplish. Plus I may have missed one or two rules...

SyncLock is generally used to protect an object not just a single routine.
For example SomeWork may be updating a total amount, other routines that
read the total amount probably should wait until the update is finished...

To better answer your question it really depends on what the SomeWork
routine is doing, and how any shared or instance variables that SomeWork
uses are being used elsewhere.

Hope this helps
Jay

"Fred" <leavemealone@home> wrote in message
news:em**************@TK2MSFTNGP10.phx.gbl... Thanks for the advice Jay. I will take your advice but I am not sure I
understand why.

Am I right in thinking that it can only be a problem if the program running between the SyncLock and End SyncLock has a possibility of recalling the
"SomeWork" sub or running another SyncLock Me.GetType somewhere.

Thanks
Fred

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:Of*************@tk2msftngp13.phx.gbl...

Fred,
I don't have links handy, however I have seen numerous recommendations

that

you should NOT use Me.GetType to lock on, that instead you should create

an

explicit "padlock" variable. The biggest reason being is you may lock on
Me.GetType for one reason, while another section of code my attempt to

lock

on Me.GetType for a different reason and you actually introduced a

deadlock!

Also Me.GetType is not instance sensitive. All instances of the class will

block on the type, which most of the time you only need to lock on the

class

instance...

The easiest way to create a "padlock" is a new object, literally "new
object"

private readonly m_padlock As New Object()

Sub SomeWork()
SyncLock m_padlock
...Code here
End SyncLock
End Sub

You can make m_padlock Shared if you need it to be across instances,

however

IMHO most of the time you do not need Shared padlocks, as you want each
instance of a class to be able to run on its own thread.

Hope this helps
Jay

"fred" <So***@NoSpam.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

If I have multiple threads running a Sub as below then a number of

threads can be held up at the SyncLock. When it becomes free which thread goes
first. Is it just by chance which thread goes first or do the threads

queue

in a FIFO or perhaps a LIFO bases.

Thanks
Fred
Sub SomeWork()
SyncLock Me.GetType
...Code here
End SyncLock
End Sub