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

Barbara E. Wójcik

dblp:32/666 · DBLP profile ↗
← Back
2ranked-venue papers
1as first author
0since 2021 · last 1991
0000-0003-0761-581XORCID · corroborated

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

Software engineering, systems software and programming languages · 2 · 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
Parallel and multicore computing · 44% Distributed systems · 40% Cloud and datacenter computing · 17%
Theoretical computer science
1 paper
Distributed computing theory · 100%

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

TopicWeightPapersLastEvidence papers
Distributed systems
fault tolerance
0.021991
Sufficient Condition for a Communication Deadlock and Distributed Deadlock Detection · IEEE Trans. Software Eng. 1989
Rough Grammar For Efficient and Fault-Tolerant Computing on a Distributed System · IEEE Trans. Software Eng. 1991
Parallel and multicore computing › task scheduling
dynamic scheduling
0.011991
Rough Grammar For Efficient and Fault-Tolerant Computing on a Distributed System · IEEE Trans. Software Eng. 1991
Parallel and multicore computing
load balancing
0.011991
Rough Grammar For Efficient and Fault-Tolerant Computing on a Distributed System · IEEE Trans. Software Eng. 1991
Cloud and datacenter computing › resource management › shared resource management
deadlock prevention
0.011989
Sufficient Condition for a Communication Deadlock and Distributed Deadlock Detection · IEEE Trans. Software Eng. 1989
Distributed systems › concurrency control › deadlock detection
distributed deadlock detection
0.011989
Sufficient Condition for a Communication Deadlock and Distributed Deadlock Detection · IEEE Trans. Software Eng. 1989

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

wait-for graph · 0.0query message protocol · 0.0rough grammar · 0.0production rules · 0.0
YearPublicationVenuePosition
1991 Rough Grammar For Efficient and Fault-Tolerant Computing on a Distributed System
abstract
A method that combines global load balancing with dynamic task scheduling on a multiprocessor machine is presented. This method does not require prior knowledge of the run times of tasks, and is based on a rough grammar representing distributed computation is presented. Production rules are dynamically constructed when a concurrent program is run. The set of the rough grammar production rules is updated and rolled in a pipeline fashion, together with codes of the processes. This pipeline fashion of rolling the jobs defines the global job balancing. The rough grammar uses any operators and metrics, not only concatenation, inside its production rules. Performance parameters for the combination of a global load balancing and decentralized dynamic task scheduling are derived and compared with those for a statically scheduled multiprocessor. Based on these parameters, the decentralized methodology is shown to attain a much higher performance level and a highly improved fault tolerance.>
Zbigniew M. Wójcik, Barbara E. Wójcik
IEEE Trans. Software Eng.2
1989 Sufficient Condition for a Communication Deadlock and Distributed Deadlock Detection
abstract
The necessary and sufficient condition for deadlock in a distributed system and an algorithm for detection of a distributed deadlock based on the sufficient condition are formulated. The protocol formulated, checks all wait-for contiguous requests in one iteration. A cycle is detected when a query message reaches the initiator. A wait-for cycle is only the necessary condition for the distributed deadlock. A no-deadlock message is expected by the query initiator to infer a deadlock-free situation if at least one wait-for cycle is present. A no-deadlock message is issued by a dependent (query intercessor) that is not waiting-for. No no-deadlock message implies a deadlock, and processes listed in the received query messages are the processes involved in a distributed deadlock. Properties of the protocol are discussed. The authors show that a replication of a requested higher-priority (or older) process can prevent a distributed deadlock (in a continuous deadlock treatment). A replication is shown to recover (in a periodical deadlock handling) a sequence of processes from an indefinite wait-die scheme.>
Barbara E. Wójcik, Zbigniew M. Wójcik
IEEE Trans. Software Eng.1