Question about Synclock and multi threading

[Chris Dunaway]

Suppose I have several threads that need to access the same object.
ThreadA successfully acquires the lock using SyncLock. ThreadB
attempts to acquire the lock and blocks and then ThreadC attempts to
acquire the lock and blocks.

When ThreadA releases the lock, will ThreadB get it before ThreadC by
virtue of the fact that ThreadB attempted to lock the object before
ThreadC did? Is there any way to enforce this sequence? I want to
make sure that ThreadB gets the lock BEFORE ThreadC. Is this possible?

[Bob Powell [MVP]]

I don't think this is possible to enforce. The checking is done at a low
level according to the processor time-slicing.

The only way I can think of to do this is for thread B to release a mutex
that thread C is waiting on.
I might be wrong. This is a stab in the dark...

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Chris Dunaway" <du******@gmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...

Suppose I have several threads that need to access the same object.
ThreadA successfully acquires the lock using SyncLock. ThreadB
attempts to acquire the lock and blocks and then ThreadC attempts to
acquire the lock and blocks.

When ThreadA releases the lock, will ThreadB get it before ThreadC by
virtue of the fact that ThreadB attempted to lock the object before
ThreadC did? Is there any way to enforce this sequence? I want to
make sure that ThreadB gets the lock BEFORE ThreadC. Is this possible?

[Cor Ligthert]

Chris,

In my opinion are you typical talking about queued information.

I never used in VBNet however would have directly a look for that when I had
a problem as yours.

http://msdn.microsoft.com/library/de...ctmessaque.asp

Cor

[Chris Dunaway]

Thanks for the replies. The queueing is not the problem. Consider the
following situation:

I have a queue in which orders are being queued and processed. There
are multiple threads retreiving items from the queue and processing
them. It is possible that two items on the queue might refer to the
same order, for example updates to the order. I need to make sure that
they occur in order. My first thought was to create a small object to
use to synchronize the threads. The first thread would acquire the
lock on that object. The second thread would wait for the lock to be
released, thereby keeping the correct sequence. But if there are 3
updates, and two are blocking, waiting for the first, I need to make
sure that the remaining two occur in order. The items will come off
the queue in order, but since there are multiple threads, I need to
make sure that they are processed in order.

Thanks again

[Cor Ligthert]

Chris,

I write this very often, don't suspect to much from threads.
When I hear about your process than is bound to the processor.

Even when it is used on multiprocessorcomputers or with hyperthreading
processors.

Your process not the only process in your computer there are a lot others.

Consider if you real need multithreading.

My sample for very good use for multithreading is forever downloading from
sites with different speeds.

To say it in other words, processes than contains stops or when you have not
dependable different queues, than it can be a good solution, however when
the queus depends from each other, than it is in my opinion better to use
let it process by one thread. Otherwise the change that you create only
overhead with multiple threading is than very high.

However just my thought,

Cor

[ABad]

You have to rethink your design. In your design, as described below, you are
forcing an order to your threads and this will lead to thread serialization,
which takes away the purpose of using multiple threads in the first place.
"Chris Dunaway" <du******@gmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...

Thanks for the replies. The queueing is not the problem. Consider the
following situation:

I have a queue in which orders are being queued and processed. There
are multiple threads retreiving items from the queue and processing
them. It is possible that two items on the queue might refer to the
same order, for example updates to the order. I need to make sure that
they occur in order. My first thought was to create a small object to
use to synchronize the threads. The first thread would acquire the
lock on that object. The second thread would wait for the lock to be
released, thereby keeping the correct sequence. But if there are 3
updates, and two are blocking, waiting for the first, I need to make
sure that the remaining two occur in order. The items will come off
the queue in order, but since there are multiple threads, I need to
make sure that they are processed in order.

Thanks again

[Chris Dunaway]

Cor Ligthert wrote:

dependable different queues, than it can be a good solution, however when the queus depends from each other, than it is in my opinion better to use let it process by one thread. Otherwise the change that you create only overhead with multiple threading is than very high.

I only have one queue. The order data comes in the form of text files
(I cannot control this). Each text file multiple orders and has order
master records and order detail records. There are multiple orders
within a single file. The orders within the file are in order
sequentially. The files are created roughly every 15 minutes. There
exists the possibility that within a single file, there could be an
order and then later in the file an update to that order. I have to
make sure the order is processed before the update to the order. If I
used just a single thread, I wouldn't have to worry about this, but I
would like to use multiple threads because some orders may take longer
to process and I want to continue to process smaller orders, to keep
the up the throughput. I understand on a single processor, multiple
threads doesn't really speed things up, but I want to increase the
throughput of orders being processed.
Thanks again for the responses.

[Cor Ligthert]

Chris,

I think that I (or any other) cannot help you, this is a lot of tuning
beside what is done in the multithreading

Your result will be a lot of overhead and as in the other message is showed,
are you in my opinion as well using a sequential process.

Thread a
Thread b wait on a
Thread a wait on b
Thread b wait on a

Cor