Demo Data from EDBT 2026 / reviewers in the wild / expert
Sarah E. Chodrow
dblp:82/1543
· DBLP profile ↗
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
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Distributed systems › distributed interactive applications
collaborative computing |
0.0 | 1 | 1998 | CCF: Collaborative Computing Frameworks · SC 1998 |
Embedded and real-time systems
runtime monitoring |
0.0 | 1 | 1991 | Run-time monitoring of real-time systems · RTSS 1991 |
Distributed systems
resource sharing |
0.0 | 1 | 1998 | 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
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1998 | Design and Implementation of a Distributed X-MultiplexorabstractApplication 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 |
ICDCS | 2 |
| 1998 | CCF: Collaborative Computing FrameworksabstractCCF (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 |
SC | 4 |
| 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 ProgramsabstractThe 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 |
ICDCS | 1 |
| 1995 | Implementation of the Sentry SystemabstractAbstract 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 ProgrammingabstractWe 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 |
ICTAI | 7 |
| 1992 | The Sentry SystemabstractA 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 |
SRDS | 1 |
| 1991 | Run-time monitoring of real-time systemsabstractA 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 |
RTSS | 1 |