RE: [boost] Threads

From: Reid Sweatman (borderland_at_[hidden])
Date: 2000-08-05 02:08:11

> -----Original Message-----
> From: Dietmar Kuehl [mailto:dietmar_kuehl_at_[hidden]]
> Sent: Friday, August 04, 2000 12:59 PM
> To: boost_at_[hidden]
> Subject: [boost] Threads

> ... and even if this will never be brought to the standardization
> committee, we should have good reasons to devote any effort from the
> Boost library: There are lots of other areas we can cover instead. So
> apart from answering the questions brought up in my previous mail, we
> should also come up with sample uses of threads where threads are
> indeed an advantage over other techniques - without any hand waving!

Okay, I'll toss out a couple I've either written or am acquainted with.  One
way of structuring a 3D renderer I've used in the past runs two threads, one
to prepare the data for the next frame, the other to render the data handed
off by the first thread in the last frame; this works particularly well on
multi-processor systems, but doesn't require it.  Likewise, most of the
third-party sound libraries for use in games run in their own thread.  And
an obvious use is to acquire some time-consumptive resource (memory, disk
files, random numbers, procedural textures, etc.) in the background by
running them as asynchronous threads.  Back when I was using a random-number
generator based on R250, which is pretty slow, I maintained two buffers, one
of which was active at any given time, the other of which was refilled by a
class-spawned thread when the active buffer fell below a preset usage level;
this minimized the chance that the PRNG would run dry (in games or
procedural textures you need lots of them in real time).  Multi-threading is
also indispensable in accessing disk files so as not to data-starve a
real-time app.

Is this the kind of examples you were looking for?

Reid Sweatman