Thread.Sleep...

[news.microsoft.com]

Hi,

Currently I have a thread thats spinning and doing a
Thread.Sleep(so meTime).

I was thinking of changing this to Thread.Sleep(Ti meout.Infinite) ; then
when I have actual data in a collection to process in this thread, I was
going to do a _thread.Interru pt(); Would this be a better approach to
spinning a thread on ?

[Jon Skeet [C# MVP]]

Re: Thread.Sleep...

news.microsoft. com <discussion@dis cussion.microso ft.com> wrote:[color=blue]
> Currently I have a thread thats spinning and doing a
> Thread.Sleep(so meTime).
>
> I was thinking of changing this to Thread.Sleep(Ti meout.Infinite) ; then
> when I have actual data in a collection to process in this thread, I was
> going to do a _thread.Interru pt(); Would this be a better approach to
> spinning a thread on ?[/color]

A better approach still would be to use Monitor.Wait and Monitor.Pulse.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Alvin Bruney]

Re: Thread.Sleep...

Jon,
how long you been writing thread code?

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a0b68 d5e8f20b779899a b@msnews.micros oft.com...[color=blue]
> news.microsoft. com <discussion@dis cussion.microso ft.com> wrote:[color=green]
> > Currently I have a thread thats spinning and doing a
> > Thread.Sleep(so meTime).
> >
> > I was thinking of changing this to Thread.Sleep(Ti meout.Infinite) ;[/color][/color]
then[color=blue][color=green]
> > when I have actual data in a collection to process in this thread, I was
> > going to do a _thread.Interru pt(); Would this be a better approach to
> > spinning a thread on ?[/color]
>
> A better approach still would be to use Monitor.Wait and Monitor.Pulse.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[news.microsoft.com]

Re: Thread.Sleep...

You can use the Q.Sychronized wrapper and not have to use lock(q) blah

The only time u need to use the lock(q) is when you are using IEnumerator as
its intrisincally blah cant spell not thread safe.

So the simpler approach in a code base would be to sleep infinte and then
interrupt that.



"Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in
message news:eZ$XiuxnDH A.1672@TK2MSFTN GP09.phx.gbl...[color=blue]
> Jon,
> how long you been writing thread code?
>
> --
>
>
> -----------
> Got TidBits?
> Get it here: www.networkip.net/tidbits
> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
> news:MPG.1a0b68 d5e8f20b779899a b@msnews.micros oft.com...[color=green]
> > news.microsoft. com <discussion@dis cussion.microso ft.com> wrote:[color=darkred]
> > > Currently I have a thread thats spinning and doing a
> > > Thread.Sleep(so meTime).
> > >
> > > I was thinking of changing this to Thread.Sleep(Ti meout.Infinite) ;[/color][/color]
> then[color=green][color=darkred]
> > > when I have actual data in a collection to process in this thread, I[/color][/color][/color]
was[color=blue][color=green][color=darkred]
> > > going to do a _thread.Interru pt(); Would this be a better approach[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > spinning a thread on ?[/color]
> >
> > A better approach still would be to use Monitor.Wait and Monitor.Pulse.
> >
> > --
> > Jon Skeet - <skeet@pobox.co m>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too[/color]
>
>[/color]

[news.microsoft.com]

Re: Thread.Sleep...

IF you need to use lock on a colleciton object you use the SynRoot. Why
bother with all that Monitor stuff and lock when you dont need to?


"news.microsoft .com" <discussion@dis cussion.microso ft.com> wrote in message
news:u1TvYzxnDH A.2592@TK2MSFTN GP10.phx.gbl...[color=blue]
> You can use the Q.Sychronized wrapper and not have to use lock(q) blah
>
> The only time u need to use the lock(q) is when you are using IEnumerator[/color]
as[color=blue]
> its intrisincally blah cant spell not thread safe.
>
> So the simpler approach in a code base would be to sleep infinte and then
> interrupt that.
>
>
>
> "Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in
> message news:eZ$XiuxnDH A.1672@TK2MSFTN GP09.phx.gbl...[color=green]
> > Jon,
> > how long you been writing thread code?
> >
> > --
> >
> >
> > -----------
> > Got TidBits?
> > Get it here: www.networkip.net/tidbits
> > "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
> > news:MPG.1a0b68 d5e8f20b779899a b@msnews.micros oft.com...[color=darkred]
> > > news.microsoft. com <discussion@dis cussion.microso ft.com> wrote:
> > > > Currently I have a thread thats spinning and doing a
> > > > Thread.Sleep(so meTime).
> > > >
> > > > I was thinking of changing this to Thread.Sleep(Ti meout.Infinite) ;[/color]
> > then[color=darkred]
> > > > when I have actual data in a collection to process in this thread, I[/color][/color]
> was[color=green][color=darkred]
> > > > going to do a _thread.Interru pt(); Would this be a better approach[/color][/color]
> to[color=green][color=darkred]
> > > > spinning a thread on ?
> > >
> > > A better approach still would be to use Monitor.Wait and[/color][/color][/color]
Monitor.Pulse.[color=blue][color=green][color=darkred]
> > >
> > > --
> > > Jon Skeet - <skeet@pobox.co m>
> > > http://www.pobox.com/~skeet
> > > If replying to the group, please do not mail me too[/color]
> >
> >[/color]
>
>[/color]

[news.microsoft.com]

Re: Thread.Sleep...

I dont want it to be spinning all the time at 100% CPU, i want it to rest
then once its interrupted, to start to spin a predefined cycle rate using
Sleep(blah) then once its empty, to go infinite again.
"Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in
message news:eZ$XiuxnDH A.1672@TK2MSFTN GP09.phx.gbl...[color=blue]
> Jon,
> how long you been writing thread code?
>
> --
>
>
> -----------
> Got TidBits?
> Get it here: www.networkip.net/tidbits
> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
> news:MPG.1a0b68 d5e8f20b779899a b@msnews.micros oft.com...[color=green]
> > news.microsoft. com <discussion@dis cussion.microso ft.com> wrote:[color=darkred]
> > > Currently I have a thread thats spinning and doing a
> > > Thread.Sleep(so meTime).
> > >
> > > I was thinking of changing this to Thread.Sleep(Ti meout.Infinite) ;[/color][/color]
> then[color=green][color=darkred]
> > > when I have actual data in a collection to process in this thread, I[/color][/color][/color]
was[color=blue][color=green][color=darkred]
> > > going to do a _thread.Interru pt(); Would this be a better approach[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > spinning a thread on ?[/color]
> >
> > A better approach still would be to use Monitor.Wait and Monitor.Pulse.
> >
> > --
> > Jon Skeet - <skeet@pobox.co m>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too[/color]
>
>[/color]

[David Sworder]

Re: Thread.Sleep...

You're right that the Thread.Interrup t() approach is better than a
Thread.Sleep(so meTime) loop. The only thing is that as I'm sure you know,
Thread.Interrup t() causes an exception to be thrown on the specified
thread... not really a problem if you catch it, but from what I read,
throwing/catching exceptions over and over again is a somewhat expensive and
inefficient thing to do.

Perhaps try a more traditional approach: Create an AutoResetEvent object
and have your worker thread call Wait() against that event object. The
thread then goes to Sleep (0% CPU utilization) until the event is "signaled"
by another thread. So when your program determines that there is work to be
done, it signals the event (see AutoResetEvent. Set()) and your worker thread
instantly "wakes up" to do its thing.

David

"news.microsoft .com" <discussion@dis cussion.microso ft.com> wrote in message
news:O4CbaGxnDH A.2080@TK2MSFTN GP10.phx.gbl...[color=blue]
> Hi,
>
> Currently I have a thread thats spinning and doing a
> Thread.Sleep(so meTime).
>
> I was thinking of changing this to Thread.Sleep(Ti meout.Infinite) ; then
> when I have actual data in a collection to process in this thread, I was
> going to do a _thread.Interru pt(); Would this be a better approach to
> spinning a thread on ?
>
>[/color]

[Jon Skeet [C# MVP]]

Re: Thread.Sleep...

Alvin Bruney <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote:[color=blue]
> how long you been writing thread code?[/color]

A fair time - why?

I'm suggesting Monitor.Wait/Pulse because they (along with
Manual/AutoResetEvents ) are specifically designed for exactly this kind
of thing.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Alvin Bruney]

Re: Thread.Sleep...

a fair time? what's that 2 days? 2 months? 2 years?
am asking when you started to actually write it, not when you first knew it
existed or heard about it.

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a0ba6 e7f49f459899ad@ msnews.microsof t.com...[color=blue]
> Alvin Bruney <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote:[color=green]
> > how long you been writing thread code?[/color]
>
> A fair time - why?
>
> I'm suggesting Monitor.Wait/Pulse because they (along with
> Manual/AutoResetEvents ) are specifically designed for exactly this kind
> of thing.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Jon Skeet [C# MVP]]

Re: Thread.Sleep...

Alvin Bruney <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote:[color=blue]
> a fair time? what's that 2 days? 2 months? 2 years?[/color]

Longer than that.
[color=blue]
> am asking when you started to actually write it, not when you first knew it
> existed or heard about it.[/color]

*Started* to write stuff using threads? About 9 years ago, when I first
started writing Java. Started thinking seriously about it and really
examining things carefully? About 4 years ago.

Again I ask: why do you want to know?

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Dave]

Re: Thread.Sleep...

As some others have pointed out, the best method to use is to wait on an
event to be signalled. A thread that is blocked waiting on an event consumes
0 cpu cycles. Using a spin-wait is the absolute worst way to wait for work
to arrive as it consumes lots of cpu cycles while producing nothing of
value. Using a thread-interrupt is better but not much. In general you
should use synchronization primitives (events, mutexes, semaphores, etc) to
synchronize access to shared resources, and execution control primitives
(suspend/resume/sleep) to control the execution state of a thread. It is
usually extremely rare that user-mode code needs to actually control the
execution state of a thread and very common to need to control the
synchronization of threads to a shared resource.


"news.microsoft .com" <discussion@dis cussion.microso ft.com> wrote in message
news:O4CbaGxnDH A.2080@TK2MSFTN GP10.phx.gbl...[color=blue]
> Hi,
>
> Currently I have a thread thats spinning and doing a
> Thread.Sleep(so meTime).
>
> I was thinking of changing this to Thread.Sleep(Ti meout.Infinite) ; then
> when I have actual data in a collection to process in this thread, I was
> going to do a _thread.Interru pt(); Would this be a better approach to
> spinning a thread on ?
>
>[/color]

[Alvin Bruney]

Re: Thread.Sleep...

> Again I ask: why do you want to know?
it is just soooo discouraging, that's all.

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a0be6 27bb6a19709899b 3@msnews.micros oft.com...[color=blue]
> Alvin Bruney <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote:[color=green]
> > a fair time? what's that 2 days? 2 months? 2 years?[/color]
>
> Longer than that.
>[color=green]
> > am asking when you started to actually write it, not when you first knew[/color][/color]
it[color=blue][color=green]
> > existed or heard about it.[/color]
>
> *Started* to write stuff using threads? About 9 years ago, when I first
> started writing Java. Started thinking seriously about it and really
> examining things carefully? About 4 years ago.
>
> Again I ask: why do you want to know?
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[news.microsoft.com]

Re: Thread.Sleep...

I used the AutoResetEvent. Set to signal the worker thread and
AutoResetEvent. WaitOne() to put it to sleep.

I dont see the need for Monitor.Wait and Monitor.Pulse as the shared item is
already using the synchronised wrapper.

I still have a spin wait so its working on the items at a good pace and not
burning the CPU from other more important threads. Is it possible to
prioritise threads?

"David Sworder" <dsworder@cts.c om> wrote in message
news:uglMjSznDH A.3732@tk2msftn gp13.phx.gbl...[color=blue]
> You're right that the Thread.Interrup t() approach is better than a
> Thread.Sleep(so meTime) loop. The only thing is that as I'm sure you know,
> Thread.Interrup t() causes an exception to be thrown on the specified
> thread... not really a problem if you catch it, but from what I read,
> throwing/catching exceptions over and over again is a somewhat expensive[/color]
and[color=blue]
> inefficient thing to do.
>
> Perhaps try a more traditional approach: Create an AutoResetEvent[/color]
object[color=blue]
> and have your worker thread call Wait() against that event object. The
> thread then goes to Sleep (0% CPU utilization) until the event is[/color]
"signaled"[color=blue]
> by another thread. So when your program determines that there is work to[/color]
be[color=blue]
> done, it signals the event (see AutoResetEvent. Set()) and your worker[/color]
thread[color=blue]
> instantly "wakes up" to do its thing.
>
> David
>
> "news.microsoft .com" <discussion@dis cussion.microso ft.com> wrote in[/color]
message[color=blue]
> news:O4CbaGxnDH A.2080@TK2MSFTN GP10.phx.gbl...[color=green]
> > Hi,
> >
> > Currently I have a thread thats spinning and doing a
> > Thread.Sleep(so meTime).
> >
> > I was thinking of changing this to Thread.Sleep(Ti meout.Infinite) ;[/color][/color]
then[color=blue][color=green]
> > when I have actual data in a collection to process in this thread, I was
> > going to do a _thread.Interru pt(); Would this be a better approach to
> > spinning a thread on ?
> >
> >[/color]
>
>[/color]

[Jon Skeet [C# MVP]]

Re: Thread.Sleep...

news.microsoft. com <discussion@dis cussion.microso ft.com> wrote:[color=blue]
> I used the AutoResetEvent. Set to signal the worker thread and
> AutoResetEvent. WaitOne() to put it to sleep.
>
> I dont see the need for Monitor.Wait and Monitor.Pulse as the shared item is
> already using the synchronised wrapper.[/color]

You're certainly only like to need *either* AutoResetEvent *or*
Monitor.Wait/Pulse, but I don't see why using a synchronised wrapper
would knock Monitor.Wait/Pulse out of the equation.
[color=blue]
> I still have a spin wait so its working on the items at a good pace and not
> burning the CPU from other more important threads.[/color]

I don't think a spin wait is a particularly good way of doing that
though - why not just sleep briefly? IIRC, the purpose of spin waits is
to wait *without* yielding to another thread, if you have a good reason
to believe that the reason you're unwilling to do more work is about to
be removed, as it were.
[color=blue]
> Is it possible to prioritise threads?[/color]

Sort of - have a look at the Thread.Priority property. Note that it
doesn't have to be honoured.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[news.microsoft.com]

Re: Thread.Sleep...

I only spin wait if the .Count is positive. so its processing at a regular
frequency. Its only doing Wait once its empty. Likely this shared
collection will come in bursts.


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a0c29 0011216dcc9899b e@msnews.micros oft.com...[color=blue]
> news.microsoft. com <discussion@dis cussion.microso ft.com> wrote:[color=green]
> > I used the AutoResetEvent. Set to signal the worker thread and
> > AutoResetEvent. WaitOne() to put it to sleep.
> >
> > I dont see the need for Monitor.Wait and Monitor.Pulse as the shared[/color][/color]
item is[color=blue][color=green]
> > already using the synchronised wrapper.[/color]
>
> You're certainly only like to need *either* AutoResetEvent *or*
> Monitor.Wait/Pulse, but I don't see why using a synchronised wrapper
> would knock Monitor.Wait/Pulse out of the equation.
>[color=green]
> > I still have a spin wait so its working on the items at a good pace and[/color][/color]
not[color=blue][color=green]
> > burning the CPU from other more important threads.[/color]
>
> I don't think a spin wait is a particularly good way of doing that
> though - why not just sleep briefly? IIRC, the purpose of spin waits is
> to wait *without* yielding to another thread, if you have a good reason
> to believe that the reason you're unwilling to do more work is about to
> be removed, as it were.
>[color=green]
> > Is it possible to prioritise threads?[/color]
>
> Sort of - have a look at the Thread.Priority property. Note that it
> doesn't have to be honoured.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]