Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Sarah E. Chodrow

dblp:82/1543 · DBLP profile ↗
← Back
8ranked-venue papers
5as first author
0since 2021 · last 1998
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 3 · 1 first-authorArtificial intelligence and machine learning · 1Security and privacy · 1 · 1 first-authorSoftware engineering, systems software and programming languages · 1 · 1 first-authorDatabases, data management, data science and information retrieval · 1 · 1 first-authorApplied, interdisciplinary, general and emerging computing · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
2 papers
Distributed systems · 77% Embedded and real-time systems · 23%

Topics — the 3 heaviest of 3, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Distributed systems › distributed interactive applications
collaborative computing
0.011998
CCF: Collaborative Computing Frameworks · SC 1998
Embedded and real-time systems
runtime monitoring
0.011991
Run-time monitoring of real-time systems · RTSS 1991
Distributed systems
resource sharing
0.011998
CCF: Collaborative Computing Frameworks · SC 1998

Methods — techniques the papers use, named apart from their topics

multiway communication · 0.0distributed data management · 0.0library function calls in c · 0.0
YearPublicationVenuePosition
1998 Design and Implementation of a Distributed X-Multiplexor
abstract
Application sharing is an important aspect of collaborative computing. One mechanism for sharing applications is a multiplexor, a tool that broadcasts input/output messages from a single client to multiple displays. We describe the design and implementation of a multiplexor for X windows that supports a heterogeneous environment and works effectively across both local and wide area networks. This X-multiplexor is composed of two distinct components, the Collaborative Computing Frameworks X-Multiplexor (CCFX) which acts as a pseudo server for the client, and the Collaborative Computing Session Manager (CCSM) which renders the client images and supplies the user interface to the system. In effect, CCSM acts as a distributed window manager, ensuring that all participants have the same view of the shared clients. This two headed approach offers significant gains in flexibility and resource usage. CCFX and CCSM can communicate using any reliable transport protocol. This can result in significant reduction of bandwidth, decreased latency, and avoids some TCP/IP communication required by the X protocol. In addition, this architecture facilitates the creation of a virtual X environment. Using this virtual environment, instead of an actual X server's environment, and then translating the virtual properties to a specific server's properties, allows for more robust support of heterogeneous systems.
Alan T. Krantz, Sarah E. Chodrow, Michael D. Hirsch, Injong Rhee, Julie Sult, Vaidy S. Sunderam
ICDCS2
1998 CCF: Collaborative Computing Frameworks
abstract
CCF (Collaborative Computing Frameworks) is a suite of software systems, communications protocols, and tools that enable collaborative, computer-based cooperative work. CCF constructs a virtual work environment on multiple computer systems connected over the Internet, to form a Collaboratory. In this setting, participants interact with each other, simultaneously access and operate computer applications, refer to global data repositories or archives, collectively create and manipulate documents or other artifacts, perform computational transformations, and conduct a number of other activities via telepresence. Research issues addressed in this project include problem solving environments and methodologies for laboratory and instrument-based scientific disciplines, and computer science issues in heterogeneous distributed systems. New approaches are being investigated and developed for fast multiway communication, robust geographically distributed data management methodologies, high-performance computational transforms inlined within collaboration sessions, and related auxiliary issues such as active documents, security, archival storage, and experiment management and control. In this paper, we discuss the design philosophy and systems rationale behind CCF, describe the major subsystems of the collaborative computing environment, and discuss the salient features of the system.
Vaidy S. Sunderam, Shun Yan Cheung, Michael D. Hirsch, Sarah E. Chodrow, Michelangelo Grigni, Alan T. Krantz, Injong Rhee, Paul A. Gray, Soeren Olesen, Phillip W. Hutto, Julie Sult
SC4
1998 Design and Implementation of a Multicast Audio Confrencing Tool for Collaborative Computing Framework
Sarah E. Chodrow, Michael D. Hirsch, Injong Rhee, Shun Yan Cheung
Inf. Sci.1
1996 Sentries for the Execution of Concurrent Programs
abstract
The sentry of a concurrent program P is a program that executes concurrently with P, periodically takes snapshots of P, and issues a warning if it detects that some snapshot does not satisfy a predefined predicate. The sentry is unique among snapshot-taking systems in its low-overhead. First, the shared storage between the observed program P and the sentry is linear in the number of P variables that are being observed. Second, the observed program P never waits for the sentry. Third, the mutual exclusion between the observed program and the sentry is achieved without using any special hardware or software constructs. In this paper, we present a family of two sentries. One sentry can be used for taking snapshots of scalar variables (and can check whether these snapshots satisfy a given propositional predicate), and the other sentry can be used for taking snapshots of complex variables such as arrays (and can check whether these snapshots satisfy a given first-order predicate). We briefly describe a system prototype for automatically generating sentries for any given concurrent program, and present some encouraging empirical results that we obtained from this prototype.
Sarah E. Chodrow, Mohamed G. Gouda
ICDCS1
1995 Implementation of the Sentry System
abstract
Abstract The sentry of a concurrent program P is a program that observes the execution of P, and issues a warning if P does not behave correctly with respect to a given set of logical properties (owing to a programming error or a failure). The synchronization between the program and sentry is such that the program never waits for the sentry, the shared storage between them is very small (in fact linear in the number of program variables being observed), and the snapshots read by the sentry are consistent. To satisfy these three requirements, some snapshots may be overwritten by the program before being read by the sentry. We develop a family of algorithms that preserve these requirements for properties involving scalar variables, then extend the algorithms to permit the observation of large data structures without additional overhead. We describe in detail the annotation language with which the properties can be expressed, and a prototype system that we have implemented to generate the sentry automatically for any given concurrent C program. Finally, we present experimental results that show that the overhead incurred by the sentry is on average no worse than ten per cent for snapshots of up to six variables, and that the loss of snapshots prevents the sentry's detection of an single violation in less than four per cent of the cases. Recurring errors are detected at a rate of 100 per cent.
Sarah E. Chodrow, Mohamed G. Gouda
Softw. Pract. Exp.1
1994 A New Approach to Modularity in Rule-Based Programming
abstract
We describe a purely declarative method for introducing modularity into forward-chaining, rule-based languages and its embodiment in the Venus rule language. The method is enforced by the syntax of the language and includes the ability to parameterize the rule groups. Drawing from two of three Venus applications developed to date, we illustrate how this form of modularity contributes directly to the resolution of certain software engineering problems associated with rule languages.>
James C. Browne, E. Allen Emerson, Mohamed G. Gouda, Daniel P. Miranker, Aloysius K. Mok, Roberto J. Bayardo, Sarah E. Chodrow, David Gadbois, F. Furman Haddix, Thomas W. Hetherington, Lance Obermeyer, Duu-Chung Tsou, Chih-Kan Wang, Rwo-Hsi Wang
ICTAI7
1992 The Sentry System
abstract
A system that observes the execution of each loop in any given sequential program and issues a warning if some loop execution does not terminate as expected (due to a programming error or a failure) is proposed. At each iteration of a loop execution, the program writes the current values of some variables into shared storage; these values are read later by another program called the sentry. The sentry uses these values to compute the loop's termination function at the current iteration, and issues a warning if successive values of the termination function are not monotonically decreasing. The shared storage between the program and the sentry is finite, the program never waits for the sentry during execution, and some form of mutual exclusion is achieved between the program and the sentry. Extensions of the system and an implementation of a prototype are described.>
Sarah E. Chodrow, Mohamed G. Gouda
SRDS1
1991 Run-time monitoring of real-time systems
abstract
A model and an implementation of a run-time environment for specifying and monitoring properties of real-time systems are presented. The proposed approach supports annotating real-time programs with events that are recorded and examined at run-time. The authors provide two general methods for synchronous or asynchronous monitoring of real-time constraints. In the synchronous case, a system constraint is embedded inside a program; thus, the constraint is examined at a particular point in the execution of a real-time task. In the asynchronous case, a constraint is monitored by a separate task during the entire execution of real-time tasks. The authors also describe an implementation of a run-time monitoring toolkit as a set of library function calls in C.>
Sarah E. Chodrow, Farnam Jahanian, Marc D. Donner
RTSS1