Threading priority

[vooose]

Consider a Server that spawns child threads to handle requests,
something of the form:

ThreadPool.QueueUserWorkItem(new WaitCallback(MyClass.HandleRequest));

and HandleRequest would look something like

public void HandleRequest(Object stateInfo)
{
//first section (lots of code)

//critical section

//end method
}

Suppose two threads are in operation, T1 and T2, where T1 was created
FIRST. Is there any way to guarantee that T1 enteres the critical
section before T2?

Suppose T1 was in the 'first section' and then T2 got control and
somehow scheduling allowed it to 'get in' to the critical section before
T1.

I guess it matters not how long the first section of code is, because at
any instance T2 could enter the Run state and beat T1 to the CS.

--
Wal
http://www.vooose.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Joakim Karlsson]

It sounds to me like you need to put the first section inside the
critical section as well. At least some of it. Unfortunately that in
essence makes the whole worker thread method synchronized, which may not
be what you want.

There is actually no guarantee that T1 starts executing code in the
HandleRequest method before T2 *at all*.

Regards,
Joakim

vooose wrote:

Consider a Server that spawns child threads to handle requests,
something of the form:

ThreadPool.QueueUserWorkItem(new WaitCallback(MyClass.HandleRequest));

and HandleRequest would look something like

public void HandleRequest(Object stateInfo)
{
//first section (lots of code)

//critical section

//end method
}

Suppose two threads are in operation, T1 and T2, where T1 was created
FIRST. Is there any way to guarantee that T1 enteres the critical
section before T2?

Suppose T1 was in the 'first section' and then T2 got control and
somehow scheduling allowed it to 'get in' to the critical section before
T1.

I guess it matters not how long the first section of code is, because at
any instance T2 could enter the Run state and beat T1 to the CS.

--
Wal
http://www.vooose.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[vooose]

Thanks for your reply. You are saying that as soon as T1.Start() is
called, and then T2.Start() after, T2 could even execute its first line
of code before T1?

ie even putting a lock on the very first line won't help me!

--
Wal
http://www.vooose.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Joakim Karlsson]

You could pass T1 an event that it signals as soon as it has reached a
safe point in your thread proc. Let the main thread wait for that event
before it starts T2.

It's hard to say without knowing your exact problem.

Joakim,
Regards

vooose wrote:

Thanks for your reply. You are saying that as soon as T1.Start() is
called, and then T2.Start() after, T2 could even execute its first line
of code before T1?

ie even putting a lock on the very first line won't help me!

--
Wal
http://www.vooose.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Lasse Vågsæther Karlsen]

vooose wrote:

Thanks for your reply. You are saying that as soon as T1.Start() is
called, and then T2.Start() after, T2 could even execute its first line
of code before T1?

ie even putting a lock on the very first line won't help me!

If you need inter-thread synchronization, you can't rely on critical
sections, you need to use signalling.

If your T1 and T2 threads are related, in such a way that T1 absolutely
must execute some piece of code before T2 get to it, then you need to
add code to both threads that guarantee that. For instance, you could
create an event object that is initially unsignalled, let T2 wait for
the event to become signalled, and let T1 signal the event when it has
completed the block of code that has to execute before T2 continues.

Throwing a few items into the thread pool will not in any way guarantee
anything about their order. Sure, the thread pool might be implemented
in such a way that it doles out the work objects to the threads in the
order it receives them, but the way the thread system works will make
these threads seem to run pretty random, ie. T1 will execute a bit, T2
will execute a bit, T7 will execute a bit, T5 will execute a bit, etc.

--
Lasse Vågsæther Karlsen
http://www.vkarlsen.no/
mailto:la***@vkarlsen.no
PGP KeyID: 0x0270466B