[IGSTK-Developers] problem with threads???
Luis Ibanez
luis.ibanez at kitware.com
Mon May 8 10:41:14 EDT 2006
From the description of the paper, it seems that the main concern
of the multi-threading approach is to allow clients of the classes
to invoke services simultaneously.
We could use multiple threads and still avoid the concern raised
by the author, if every IGSTK component is still receiving its
request through a *single* queue of inputs. This approach has the
advantage that it is compatible for also supporting a multiple
process implementation of the components. That is, an architecture
where every IGSTK component runs as an independent process.
The implementation of the *single input queue* requires to use
stubs (or proxies) for every IGSTK component. Clients of IGSTK
component will talk to the stubs and invoke through them all the
public "Request" methods. The stubs will translate the requests
into inputs (potentially with data payloads) that will be pushed
in to the queues of their associated IGSTK component. The process
of pushing data into the queues is the only one that will require
the use of mutual exclusion, so only one proxy is writing to the
queue at every given moment.
The input queues themselves could be implemented using pipes or sockets.
Splitting IGSTK components into the part that manages "Requests" (this
is the proxy or stub), and the part that processes those request (this
is the actual IGSTK component whose methods are all private) makes
possible to prevent one request to perturb the execution of an action,
because now requests are not being executed by the same class that
performs the action.
In this context, the combination of (proxy + input queue) plays
the role of the "merge" block component described in the paper.
Since IGSTK components will read inputs from their queues, there is
no opportunity for the component to be interrupted with a request
before it finishes attending another request.
This is again, a way of getting IGSTK back to a message-passing
architecture.
===
BTW: On the bright side, the author describe a software engineering
process that is close to IGSTK's:
> Part of the Ptolemy Project experiment sought to determine whether we
> could develop effective software engineering practices for an
> academic research setting. We developed a process that included a
> four-level code maturity rating system (red, yellow, green, and
> blue), design reviews, code reviews, nightly builds, regression
> tests, and automated code coverage metrics. We wrote the kernel
> portion that ensured a consistent view of the program structure in
> early 2000, design reviewed to yellow, and code reviewed to green.
> The reviewers included concurrency experts, not just inexperienced
> graduate students.
>
> We wrote regression tests that achieved 100 percent code coverage.
> The nightly build and regression tests ran on a two-processor SMP
> machine, which exhibited different thread behavior than the
> development machines, which all had a single processor.
With the difference that we are still hanging at 95% code coverage :-/
Luis
===================
David Robbi wrote:
> Hi Kevin,
>
> It is definitely true that multi-threading in C++ has one very important
> safety drawback: threads share memory with one another and it is very
> hard to validate that one of the threads isn't touching memory that it
> isn't supposed to. Hence the idea of using multiple processes instead
> of multiple threads has come up in our technical discussions. The only
> real advantage of threads is efficiency, since all memory is shared
> instead of data being passed over sockets or pipes.
>
> Overall, though, I don't see why threads are any less deterministic than
> other models for concurrent programming (haven't read the paper yet). I
> just see them as harder to validate and harder to debug, particularly in
> a language like C++ that wasn't designed with multi-threading in mind.
>
> - David
>
>
> Kevin Cleary wrote:
>
>>
>> As noted by Ziv Yaniv from our group - see the May issue of IEEE
>> Computer (obviously not as good as the previous issue with our article ;)
>>
>>
>>
>> It really advocates not using threads as they cause programs to be
>> nondeterministic, and very unsafe in many cases. This goes against the
>> IGSTK spirit of extreme safety.
>>
>>
>>
>> I don't think we should change anything we did for the proposal - this
>> is just FYI
>>
>>
>>
>> Kevin
>>
>>
>>
>> The Problem with Threads
>> Edward A. Lee
>> <http://search2.computer.org/advanced/Author_Result.jsp?qtype=3&select=50&qOpt1=DC_CREATOR&sortOrder=d&queryName=Edward%20A.%20Lee>,
>> University of California, Berkeley
>>
>> Full Article Text: Download PDF of full textBuy this article
>> <https://newton.computer.org/DocDelivery/Shopping.nsf/AddToCart?OpenAgent&U=http://csdl.computer.org/dl/mags/co/2006/05/r5033.pdf&T=The%20Problem%20with%20Threads>
>>
>>
>> **DOI Bookmark: **http://doi.ieeecomputersociety.org/10.1109/MC.2006.180
>>
>> *Abstract*
>>
>> For concurrent programming to become mainstream, we must discard
>> threads as a programming model. Nondeterminism should be judiciously
>> and carefully introduced where needed, and it should be explicit in
>> programs.
>>
>>
>>
>> *Back to Top
>> <http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/&toc=comp/mags/co/2006/05/r5toc.xml&DOI=10.1109/MC.2006.180#top>
>> *
>>
>> *Additional Information *
>>
>> *Index Terms-* Programming paradigms, Threads, Nondeterminism, Design
>> patterns, Coordination languages
>>
>> **Citation:** Edward A. Lee, "The Problem with Threads," /Computer/,
>> vol. 39, no. 5, pp. 33-42, May, 2006.
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------
>>
>> Kevin Cleary, Ph.D. Work phone: 202-687-8253
>>
>> Associate Professor Work fax: 202-784-3479
>>
>> Deputy Director
>>
>> Imaging Science and Information Systems (ISIS) Center
>>
>> Department of Radiology Pager: 202-901-2033
>>
>> Georgetown University Medical Center Cell phone: 202-294-3409
>>
>> 2115 Wisconsin Avenue, Suite 603 Home phone: 301-299-0788
>>
>> Washington, DC, 20007 Home fax: 301-299-0789
>>
>>
>>
>> ISIS center: www.isis.georgetown.edu
>>
>> Research group: www.caimr.georgetown.edu
>>
>> WashCAS: www.washcas.org
>>
>> Email: cleary at georgetown.edu
>>
>> -------------------------------------------------------------------
>>
>>
>>
>> -----Original Message-----
>> From: Ziv Yaniv [mailto:zivy at isis.imac.georgetown.edu]
>> Sent: Saturday, May 06, 2006 11:45 PM
>> To: cleary at isis.georgetown.edu
>> Subject: misc
>>
>>
>>
>> Hi Kevin,
>>
>>
>>
>> I forgot to let you know I'd be working from home on monday.
>>
>>
>>
>> The more interesting thing is a paper in the last issue of computer
>> (got it today). From what I've seen of the upcoming IGSTK proposal
>> part of it includes multi-threading. In this issue of computer there
>> is a paper called "The Problem with Threads". It really advocates not
>> using threads as they cause programs to be nondeterministic, and very
>> unsafe in many cases. This goes against the IGSTK spirit of extreme
>> safety.
>>
>>
>>
>> Ziv
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> IGSTK-Developers mailing list
>> IGSTK-Developers at public.kitware.com
>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
>
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
>
More information about the IGSTK-Developers
mailing list