Re: Proper time to thread?
Re: Proper time to thread?
- Subject: Re: Proper time to thread?
- From: Becky Willrich <email@hidden>
- Date: Fri, 31 May 2002 10:09:41 -0700
One other point - event-driven programming is just more flexible all around than threaded, blocking. For instance, switching from an event-driven, single-threaded model to a threaded one is easy (just run whatever it is that's detecting the events on a separate thread and voila - you're threaded), but switching from threaded, blocking to event-driven is very hard (because suddenly code that thought it had private access to state no longer does). Or if you ever want to add other processing to the I/O thread(s), or in any way interrupt them, that's much easier to do when event-driven - there are well-defined moments (whenever you're detecting new events) when you have control of the thread, and can easily schedule other tasks. So if you're unsure of which model to use, I'd choose event-driven; it preserves your options. It's more code up-front (blocking on a separate thread is definitely easy code to write), but I find that the extra code is just enforcing good coding practices like encapsulation that you would eventually have needed anyway.
Finally, although theoretically a threaded, blocking model yields as good or better throughput than an event-driven model (better because you're not paying the cost of the event-detection mechanism), in practice, I find event-driven yields higher throughput because if there's any cross-thread update, the locking required artificially slows everything down. Note that this is true even if there's no contention for the lock - simply taking and releasing a lock requires some kind of cross-thread synchronization, and often means momentarily halting the other threads (there may be some clever tricks to avoid this, but I don't know them).
Threads aren't all their made out to be,
REW
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.