Subject: Re: Commit: back out martin's changes ;-(
From: Dom Lachowicz (dominicl@seas.upenn.edu)
Date: Wed Sep 05 2001 - 12:13:35 CDT
Hi,
> I was working on a Win32 idle loop. I think I'll finish anyway, since
> I'm almost done. Ignore it if you like.
No, please do this.
> SDL and wxWindows each have XP thread libs. In wxWindows, there are
> 1200-1500 LOC per platform for threads, mutexen, and condition
> variables.
Yeah, that's quite high. My mutexen are about 20LOC TOTAL. No conditional
variables (yet) or actual threads.
> By the way, I'd help with multithreading. I have Win2k, MacOS X, and
> Linux/Gnome machines, so I can work on several platforms.
This is great.
> I'm confused about the goal here. I don't see what's wrong with timers
> and idle handlers.
They are being used as a "poor man's" thread.
> As long as they send everything through the event
> queue, the program is effectively single-threaded, even if the system
> uses multiple threads to make it happen. There shouldn't be any race
> conditions.
They interrupt current flows of execution and cause race conditions. This is
most noticable on BeOS, but we have conditional variables inside of the Piece
Table and Formatter to *try* to prevent race conditions. Consider the
following scenarios. 'A' is the initial context, and 'B' is what happens when
the timer fires:
Scenario 1: Cursor
A) inside of code disabling cursor blinking
B) cursor timer fires
B) cursor redraws, resets its internal state
A) continues disabling cursor blinking without regard to the internal state
change
Scenario 2: Autosave
A) inside of code disabling autosave
B) autosave timer fires
B) document gets auto-saved, resets some internal state (especially bad inside
of a timer because this can be a *long* blocking operation)
A) continues as if nothing had happened
Scenario 3: Piece Table
A) changing piece table
B) coalesce thread fires
B) we now coalesce some runs
A) continues changing the piece table. what does the internal state look like
now?
I hope that you see my point... This list is certainly non-exhaustive. By
using timers, we are, in effect, becoming our own thread library and
scheduling context-swaps ourselves and using booleans as mutexes, which is a
*bad* thing. With threads, we gain the support of an *actual* kernel or
userspace scheduler as well as (potentially) splitting work across a SMP
machine's processors.
Dom
This archive was generated by hypermail 2b25 : Wed Sep 05 2001 - 12:13:37 CDT