Re: creating multiple NSTimers
Re: creating multiple NSTimers
- Subject: Re: creating multiple NSTimers
- From: Tom Hohensee <email@hidden>
- Date: Fri, 30 Sep 2011 07:07:38 -0500
Thanks for the discussion. What I implemented last night was what Graham had suggested. I simply bind my table column values to an NSArrayController controller and observed by KVO in my set box object. It works great. I think this is also what Conrad had meant as well. Simply changing the time updates or invalidates the timer for each box. It is far more elegant that what I was originally doing.
Not to carry this discussion too long, I created this confusion in my head by looking at a project I did 4 years ago while developing a sprinkler controller. In that project I ended up creating a schedule object which was a property for each relay on a controller board which was as an object as well. Each relay (sprinkler zone) had an address, on and off commands and an indeterminate number of schedule objects as properties. If you think about this it is quite challenging as you can very easily end up with 100's of timers on the run loop at any one time. Many of these timers (on a 7 day schedule) would be sitting around for days waiting to fire. For just one relay you would have at a minimum 2 timers (on and off timers) a day. Each relay was on a relay board with 12 relays. Complicating matters was the fact that here (drought stricken Texas) many areas are running a sprinkler zone at multiple short interval times per day (mainly at night). To avoid having all of these timers on the run loop I ended up using the one initial timer that when fired started a loop through the array of timers. But keep in mind that each "on" command timer also had an "off" command timer as well as setting up the next on timer. Also keep in mind that only one zone can be on at a time due to water pressure (this being the difference between this set top box project and the sprinkler project). etc.........
Anyway food for thought.
Tom
On Sep 30, 2011, at 3:37 AM, Conrad Shultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 9/30/11 12:29 AM, Thomas Davie wrote:
>
>>> When the user updates a timer, one is forced to re-sort the
>>> array and reposition the index (under the above implementation).
>>
>> Why would you need to resort? Just remove, and reinsert.
>
> OK, I'll grant you it's a fast re-sort, but you still have to find the
> new insertion point and move the index (if needed).
>
>>> One would also have to implement the scheme carefully,
>>> particularly if the shut-off code is offloaded onto separate
>>> threads, to avoid potential race conditions arising from a user
>>> changing a fire date in the middle of a shut-off sequence.
>>
>> Careful locking required in multithreaded environment –
>> unsurprising.
>
> Of course, though my gut feeling (admittedly happening at a time of
> day where I'm fast fading and likely to put my foot in my mouth...) is
> that the locking would be simpler if one had discrete timers that can
> be scattered across threads (or run their invocations on separate
> threads - though that might be unsuitable for the task at hand). I
> haven't sat down and implemented this (as you evidently have), so I
> must confess I don't have much to stand on here.
>
>>> And as Graham mentioned, polling is probably less CPU and power
>>> efficient than using timers anyway.
>>
>> Who's suggesting polling - you simply have one timer set for the
>> time at which the first of your actual timers goes off. When it
>> goes off, you fire the first of your actual timers, and reschedule
>> your "when do other timers go off" timer.
>
> OK, my apologies, I got turned around and had the earlier suggestion
> about a high-resolution poll still stuck in my head. You're
> absolutely right - no one is suggesting polling in the above.
>
>>> Am I missing something conceptually here? Why are people
>>> pushing for the single timer model? Is there some hidden
>>> complexity in a multi-timer approach that I'm not seeing?
>>
>> I implemented the single timer model yesterday, but I have to
>> admit, the reason was because I'm targeting GNUstep, and when I
>> stared at their source I discovered that they simply itterate
>> through *all* timers every run loop iteration checking if they've
>> gone off, their code also starts NSLogging warnings if you have
>> more than 1000 timers. I have no idea if apple's solution is
>> better than GNUstep's, but if it isn't, the single timer approach
>> would be vastly beneficial.
>
> Wow, I have to imagine there are a fair number of timers getting fired
> off throughout the system all the time for various tasks and that
> Apple would have optimized it more thoroughly.
>
> But a cursory inspection of the most recent open source CFRunLoop.c
> suggests that indeed is what is happening inside __CFRunLoopDoTimers.
> It's possible that I'm missing something in my tired state, but it
> sure does look like a simple loop. (There's a lot of magic happening
> in __CFRunLoopDoTimer, but it still gets called during each loop
> iteration.)
>
> Huh... color me surprised.
>
> Thanks for the response (and putting up with me).
>
> - --
> Conrad Shultz
>
> Synthetiq Solutions
> www.synthetiqsolutions.com
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6Ff6wACgkQaOlrz5+0JdXnYwCeL8dCMMzWdLxigqgak56ADr9U
> jQUAnjltbDhavl2/PiwUiD7O+HofAU/Q
> =Yo8x
> -----END PGP SIGNATURE-----
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden