threading

[Perecli Manole]

I have a background worker thread that receives queued work items and
processes them. How do I make this background thread go in a sleep state
while the queue is empty and then wake back up as soon as there are work
items to be performed?

To much processor time is being wasted right now checking an empty queue in
a loop.

Thanks
Perry

[Armin Zingler]

"Perecli Manole" <Pe*****@dslext reme.com> schrieb

I have a background worker thread that receives queued work items
and processes them. How do I make this background thread go in a
sleep state while the queue is empty and then wake back up as soon as
there are work items to be performed?

To much processor time is being wasted right now checking an empty
queue in a loop.

Can you add Thread.Sleep(10 0) inside the loop?
--
Armin

[Jay B. Harlow [MVP - Outlook]]

Perecli,
In addition to Armin's suggestion. I normally use a
System.Threadin g.AutoResetEven t along with the queue. Depending on the
parameters you pass to the AutoResetEvent. WaitOne method, the background
thread will sleep indefinitely waiting for the event to be signaled.

The background thread has two loops. The outer loop does an
AutoResetEvent. WaitOne waiting for the event to be signaled. When the event
is signaled the background thread has an inner loop processing each item in
the queue.

When other threads put work items into the queue they Set the above
AutoResetEvent, letting the background thread know there is at least one
item in the queue.

Normally I put the Thread, the AutoResetEvent, the Queue and the padlock for
the Queue into a single class that represents the "Worker". Encapsulating
the above into clean type safe methods.

Hope this helps
Jay

"Perecli Manole" <Pe*****@dslext reme.com> wrote in message
news:Ov******** ******@tk2msftn gp13.phx.gbl...

I have a background worker thread that receives queued work items and
processes them. How do I make this background thread go in a sleep state
while the queue is empty and then wake back up as soon as there are work
items to be performed?

To much processor time is being wasted right now checking an empty queue in a loop.

Thanks
Perry

[Fergus Cooney]

Hi Perry,

You'd have your Thread sleep when it has finished. Whenever the Queue
receives another Job, it would check the Thread. If it's asleep, you can send
an interrupt. This will cause an Exception which must be caught. [Don't send
the Interrupt if the Thread is not asleep - the Interrupt will hang around
until it <does> go to sleep and then wake it up immediately!!]

Something like the following:

Regards,
Fergus

<code>
In Queue:
oThread As Thread

Sub NewJob (..)
'Add Job to Queue
: : :
If oThread.ThreadS tate = ThreadState.Wai tSleepJoin Then
oThread.Interru pt 'Hey!! Sleepy Head! - I've a job for you.
End If
End Sub

Sub FinishTheJobAnd GoHome(..)
While oThread.ThreadS tate <> ThreadState.Wai tSleepJoin
Thread.Sleep (SomeDelay)
End While
oThread.Abort.
oThread.Join.
End Sub

In Worker
Try
Do
'Busy, busy
: : :
If NoMoreJobs Then
'Done for now
Try
Thread.Sleep (Inifinite) 'ZZZzzzz....
Catch e As ThreadInterrupt edException
'Yawn, .. streeeetch,... better get back to work.
End Try
Loop
Catch e As ThreadAbortExce ption
'Hurray - knocking off time!!
End Try
</code>

[Perecli Manole]

It seems like the AutoResetEvent is the best approach.

I don't understand the padlock element you speak of.
Right now I have something like this but want to get rid of Sleep():

Public Sub SubmitCmd(ByVal objCommand As ICmdExecute)
If Not m_objBgThread Is Nothing Then
SyncLock m_objCmdQueue.S yncRoot
m_objCmdQueue.E nqueue(objComma nd)
End SyncLock
End If
End Sub

Private Sub BackgroundThrea d()
Dim objCommand As ICmdExecute

While True
'dequeue all available commands
Do
SyncLock m_objCmdQueue.S yncRoot
If m_objCmdQueue.C ount > 0 Then
objCommand = m_objCmdQueue.D equeue()
End If
End SyncLock

If objCommand Is Nothing Then
Exit Do
Else
objCommand.Exec ute()
objCommand = Nothing
End If
Loop

Thread.Sleep(50 ) 'prevents hoggin up all the CPU's time
End While
End Sub

Should the AutoResetEvent. Set be within the synclock block or out?
What if the AutoResetEvent. Set is executed right before the background
thread is about to call AutoResetEvent. WaitOne? This could halt the
background thread indefinitely even though there are queued items.

Thanks
Perry

"Jay B. Harlow [MVP - Outlook]" <Ja********@ema il.msn.com> wrote in message
news:eL******** ******@TK2MSFTN GP10.phx.gbl...

Perecli,
In addition to Armin's suggestion. I normally use a
System.Threadin g.AutoResetEven t along with the queue. Depending on the
parameters you pass to the AutoResetEvent. WaitOne method, the background
thread will sleep indefinitely waiting for the event to be signaled.

The background thread has two loops. The outer loop does an
AutoResetEvent. WaitOne waiting for the event to be signaled. When the event is signaled the background thread has an inner loop processing each item in the queue.

When other threads put work items into the queue they Set the above
AutoResetEvent, letting the background thread know there is at least one
item in the queue.

Normally I put the Thread, the AutoResetEvent, the Queue and the padlock for the Queue into a single class that represents the "Worker". Encapsulating
the above into clean type safe methods.

Hope this helps
Jay

"Perecli Manole" <Pe*****@dslext reme.com> wrote in message
news:Ov******** ******@tk2msftn gp13.phx.gbl...

I have a background worker thread that receives queued work items and
processes them. How do I make this background thread go in a sleep state
while the queue is empty and then wake back up as soon as there are work
items to be performed?

To much processor time is being wasted right now checking an empty queue

in

a loop.

Thanks
Perry