Re: Suggestion for review: a taxonomy of thread safety
From: Nick Landsberg (SPAMhukolauTRAP_at_SPAMworldnetTRAP.att.net)
Date: 09/24/04
- Previous message: Gerry Quinn: "Re: Input on graphic libraires"
- In reply to: Jim Rogers: "Re: Suggestion for review: a taxonomy of thread safety"
- Next in thread: Jim Rogers: "Re: Suggestion for review: a taxonomy of thread safety"
- Reply: Jim Rogers: "Re: Suggestion for review: a taxonomy of thread safety"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 24 Sep 2004 12:52:29 GMT
Jim Rogers wrote:
> Nick Landsberg <SPAMhukolauTRAP@SPAMworldnetTRAP.att.net> wrote in
> news:7EK4d.625843$Gx4.47450@bgtnsc04-news.ops.worldnet.att.net:
>
>
>>To possibly turn this discussion to somewhat differnt
>>aspect:
>>
>>"If multi-threading is the answer, what's the question?"
>>
>>In my experience, threading is useful if:
>>you have threads (flows of control) which must wait
>>on slow devices, e.g. disks, networks, etc.
>>(Not the only case, the most obvious case.)
>>
>>In this situation, you may have some thread perform
>>useful computations while the another thread is waiting
>>for the response.
>
>
> I have successfully implemented event-based robotic control
> systems using multiple threads of control. My program had no
> problems with locking and unlocking of data. The reason my
> program had no such problems was because I used a language
> that implicitly takes care of those issues.
>
> The language is Ada. The multi-tasking implementation is
> very robust, very flexible, and highly reliable.
>
> Examples:
>
> On a robotic system some sensor information, such as
> vehicle heading, is delivered at a constant rate which
> may exceed the system's sampling needs. In that case,
> the system needs to read the most recent value from
> the sensor, and does not need to be flooded with values
> it cannot handle.
>
> One task can read from the sensor at the sensor's
> specified rate. It will write to a shared memory area.
> Another task will read the shared memory area at a
> slower rate; the rate which the system can process the
> data. How does one set up a shared memory area such that
> memory writes are locked, but memory reads are not (allowing
> reads to be as fast as possible)? One Ada solution is:
>
[SNIP]
What you posted, Jim, has many things going
for it. In addition to the language support
(the more I hear about ADA the more I'm impressed),
what you described was a very disciplined design
to begin with. (Having the language support looks to
have made the implementation easier.)
From a language independent point of view, the
design is more critical. Take a design, for
instance, where there are multiple writers
and multiple readers of multiple shared
resources. Whenever I run across
one of those, I start to worry, for a number
of reasons. It might be legitimate, but often
it is due to some newbie deciding to multi-thread
his/her existing code without thinking through
the ramifications. In the extreme, you can wind
up with slower execution than if you had left
it single-threaded in the first place.
Thanks for the post.
NPL
-- "It is impossible to make anything foolproof because fools are so ingenious" - A. Bloch
- Previous message: Gerry Quinn: "Re: Input on graphic libraires"
- In reply to: Jim Rogers: "Re: Suggestion for review: a taxonomy of thread safety"
- Next in thread: Jim Rogers: "Re: Suggestion for review: a taxonomy of thread safety"
- Reply: Jim Rogers: "Re: Suggestion for review: a taxonomy of thread safety"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|