Threading/Locking

[Shane]

I have a question about locks because I am seeing behavior that does not
match what I though was the correct behavior. I thought when you put a lock
around code the first instance that ran it would of course get access and
then each access after that (while the first instance is still executing the
code) would be essentially queued up on that lock waiting for the first to
exit. But what I am seeing is that the last one there is the first to get
access to the code... which doesn't make sense. If someone can shed some
light I would appreciate it. Below is an example of the code and the data
that it returned you can see that 4 lines that were logged before the lock
and the last one was the first to go inside the lock????

5/11/2005 11:26:43 AM - Data Before Lock: ==============
5/11/2005 11:26:43 AM - Data Before Lock: ==============
5/11/2005 11:26:43 AM - Data Before Lock: ==============
5/11/2005 11:26:43 AM - Data Before Lock: ======= DATE
5/11/2005 11:26:43 AM - Data After Lock: ======= DATE
5/11/2005 11:26:43 AM - Data Before Lock: of BIRTH: 12/
5/11/2005 11:26:43 AM - Data After Lock: of BIRTH: 12/
5/11/2005 11:26:43 AM - Data After Lock: ==============
5/11/2005 11:26:43 AM - Data After Lock: ==============
5/11/2005 11:26:43 AM - Data After Lock: ==============
//lockingObject is a private object contained in the class with this method
public void getIncomingData(object data)
{
try
{
myLog.Log(string.Format("Data Before Lock: {0}",data),true);
lock(lockingObject)
{
myLog.Log(string.Format("Data After Lock: {0}",data),true);
myParser.getIncomingData((string)data);
}
}
catch(Exception e)
{
myLog.Log(string.Format("Error in DataCapture getIncomingData:
{0}",e.Message));
}
}

[Jon Skeet [C# MVP]]

Shane <Sh***@discussions.microsoft.com> wrote:

I have a question about locks because I am seeing behavior that does not
match what I though was the correct behavior. I thought when you put a lock
around code the first instance that ran it would of course get access and
then each access after that (while the first instance is still executing the
code) would be essentially queued up on that lock waiting for the first to
exit. But what I am seeing is that the last one there is the first to get
access to the code... which doesn't make sense. If someone can shed some
light I would appreciate it. Below is an example of the code and the data
that it returned you can see that 4 lines that were logged before the lock
and the last one was the first to go inside the lock????

There's no guaranteed ordering involving in who acquires the lock when.
I don't believe it's specified to be FIFO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Shane]

So what is the suggested solution to this...I need the data to be handled in
order, but I don't want to have to block the sending thread because the data
coming in is time sensitive (ie needs to be retrieved quickly).

thanks for your help.

"Jon Skeet [C# MVP]" wrote:

Shane <Sh***@discussions.microsoft.com> wrote:

I have a question about locks because I am seeing behavior that does not
match what I though was the correct behavior. I thought when you put a lock
around code the first instance that ran it would of course get access and
then each access after that (while the first instance is still executing the
code) would be essentially queued up on that lock waiting for the first to
exit. But what I am seeing is that the last one there is the first to get
access to the code... which doesn't make sense. If someone can shed some
light I would appreciate it. Below is an example of the code and the data
that it returned you can see that 4 lines that were logged before the lock
and the last one was the first to go inside the lock????

There's no guaranteed ordering involving in who acquires the lock when.
I don't believe it's specified to be FIFO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Alan Pretre]

"Shane" <Sh***@discussions.microsoft.com> wrote in message
news:59**********************************@microsof t.com...

I have a question about locks because I am seeing behavior that does not
match what I though was the correct behavior. I thought when you put a
lock
around code the first instance that ran it would of course get access and
then each access after that (while the first instance is still executing
the
code) would be essentially queued up on that lock waiting for the first to
exit. But what I am seeing is that the last one there is the first to get
access to the code... which doesn't make sense. If someone can shed some
light I would appreciate it. Below is an example of the code and the data
that it returned you can see that 4 lines that were logged before the lock
and the last one was the first to go inside the lock????

I was wondering, are you sure there is not already a lock on lockingobject
before that first try?

-- Alan

[Shane]

Those log messages were not the first calls they were further down the list
there had already been locks put on that object, but that is the only place
that I am using that object.

[Alan Pretre]

"Shane" <Sh***@discussions.microsoft.com> wrote in message
news:F9**********************************@microsof t.com...

Those log messages were not the first calls they were further down the
list
there had already been locks put on that object, but that is the only
place
that I am using that object.

One thing you can do is give unique names to all of the threads you create
and put a breakpoint at/after the lock and see who is getting in. You can
also freeze threads in the debugger while concentrating on the one of
interest.

-- Alan

[Jon Skeet [C# MVP]]

Shane <Sh***@discussions.microsoft.com> wrote:

So what is the suggested solution to this...I need the data to be
handled in order, but I don't want to have to block the sending
thread because the data coming in is time sensitive (ie needs to be
retrieved quickly).

Then you stash the data in an ordered list which is then processed by
another thread.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Shane]

I know what thread is calling the function thats not really the problem its
the behavior. I need a way to make sure that the threads are executed in the
order that they were spun off. Or at least to work on the data in the order
that it comes in.

Thanks for your help

"Alan Pretre" wrote:

"Shane" <Sh***@discussions.microsoft.com> wrote in message
news:F9**********************************@microsof t.com...

Those log messages were not the first calls they were further down the
list
there had already been locks put on that object, but that is the only
place
that I am using that object.

One thing you can do is give unique names to all of the threads you create
and put a breakpoint at/after the lock and see who is getting in. You can
also freeze threads in the debugger while concentrating on the one of
interest.

-- Alan

[Alan Pretre]

"Shane" <Sh***@discussions.microsoft.com> wrote in message
news:96**********************************@microsof t.com...

I know what thread is calling the function thats not really the problem its
the behavior. I need a way to make sure that the threads are executed in
the
order that they were spun off. Or at least to work on the data in the
order
that it comes in.

Yes I think that is a problem. You can't really control the timeslices that
the threads receive and so there really is no guarantee on who will arrive
at the gate first. If there is one point of arrival it would be better to
have only one thread fetching. You can have other threads doing the
processing from the collection.

You can use a System.Collections.Queue object and can coordinate the storing
and retrieving on the queue through its SyncRoot member. It is optimized
for multithreaded access to the collection. This would eliminate your
lockingobject.

-- Alan

[Shane]

Thanks for your help Alan...

Thats what I ended up doing putting the data into a Queue and then creating
a thread and then using the SyncRoot of the Queue to lock it so that the data
was read out of the queue in the order it came in.

Thanks all.

"Alan Pretre" wrote:

"Shane" <Sh***@discussions.microsoft.com> wrote in message
news:96**********************************@microsof t.com...

I know what thread is calling the function thats not really the problem its
the behavior. I need a way to make sure that the threads are executed in
the
order that they were spun off. Or at least to work on the data in the
order
that it comes in.

Yes I think that is a problem. You can't really control the timeslices that
the threads receive and so there really is no guarantee on who will arrive
at the gate first. If there is one point of arrival it would be better to
have only one thread fetching. You can have other threads doing the
processing from the collection.

You can use a System.Collections.Queue object and can coordinate the storing
and retrieving on the queue through its SyncRoot member. It is optimized
for multithreaded access to the collection. This would eliminate your
lockingobject.

-- Alan