Preemption and Federalism: the Missing Link, 16 Hastings Const

Total Page:16

File Type:pdf, Size:1020Kb

Load more

Hastings Constitutional Law Quarterly Volume 16 Article 3 Number 1 Fall 1988 1-1-1988 Preemption and Federalism: The iM ssing Link Paul Wolfson Follow this and additional works at: https://repository.uchastings.edu/ hastings_constitutional_law_quaterly Part of the Constitutional Law Commons Recommended Citation Paul Wolfson, Preemption and Federalism: The Missing Link, 16 Hastings Const. L.Q. 69 (1988). Available at: https://repository.uchastings.edu/hastings_constitutional_law_quaterly/vol16/iss1/3 This Article is brought to you for free and open access by the Law Journals at UC Hastings Scholarship Repository. It has been accepted for inclusion in Hastings Constitutional Law Quarterly by an authorized editor of UC Hastings Scholarship Repository. For more information, please contact [email protected]. ARTICLE Preemption and Federalism: The Missing Link By PAUL WOLFSON* Introduction As a weapon against state economic and social regulation, the pre- emption doctrine threatens to become the new Lochner.1 As the states take up much of the regulatory power that Congress has forsworn,2 cor- porations are advancing the Supremacy Clause3 as an obstacle to state regulation in fields such as environmental protection,' employment dis- crimination,' labor law,6 nuclear power,7 workplace safety,8 and securi- ties.9 The courts have had many opportunities to develop a readily applied preemption doctrine. Preemption cases have reached the Supreme Court frequently because they have often come within the * Associate, Wilmer, Cutler & Pickering, Washington, D.C., J.D. Yale Law School, 1987. The author wishes to thank Betsy Cavendish, Michael Froomkin, and Paul Kahn for their many helpful comments and suggestions. 1. Lochner v. New York, 198 U.S. 45 (1905) (New York statute limiting bakers to 60 'hour work week violated Due Process Clause of Fourteenth Amendment). 2. See, eg., Can-Do Capitals: States Enlarge Roles As Congress Is Unable To Solve Problems, Wall St. J., June 28, 1988, at 1, col. 1. 3. "This Constitution, and the Laws of the United States which shall be made in Pursu- ance thereof.., shall be the supreme Law of the Land; and the Judges in every State shall be bound thereby, any Thing in the Constitution or Laws of any State to the Contrary notwith- standing." U.S. CONST. art. VI, cl. 2. 4. See California Coastal Comm'n v. Granite Rock Co., 107 S. Ct. 1419 (1987); Interna- tional Paper Co. v. Ouellette, 107 S. Ct. 805 (1987). 5. See California Fed. Sav. & Loan Ass'n v. Guerra, 107 S. Ct. 683 (1987). 6. See Allis-Chalmers Corp. v. Lueck, 471 U.S. 202 (1985). 7. See Pacific Gas & Elec. Co. v. State Energy Resources & Dev. Comm'n, 461 U.S. 190 (1983). 8. See Note, Getting Away with Murder: Federal OSHA Preemption of State Criminal Prosecutionsfor IndustrialAccidents, 101 HARV. L. RaV. 535 (1987). 9. See CTS Corp. v. Dynamics Corp. of Am., 107 S. Ct. 1637 (1987); Edgar v. MITE Corp., 457 U.S. 624 (1982). HASTINGS CONSTITUTIONAL LAW QUARTERLY [Viol. 16:69 Court's mandatory appellate jurisdiction."0 When it can do so, the Court usually bases its rulings on preemption rather than other constitutional provisions because preemption cases concern congressional intent, and therefore Congress can overturn the Court's interpretation if the Court is mistaken." Yet frequent opportunities to refine .preemption doctrine have not yielded a consistent jurisprudence. Although the Supreme Court has referred to four categories of pre- emption in almost every one of its recent preemption cases, 12 the catego- 10. Until-recently, parties could appeal of right to the Supreme Court fromfederal appel- late decisions striking down- state statutes as."repugnant to the Constitution, treaties, or laws of the United States," 28 U.S.C. § 1254(2) (1982), and from state court decisions upholding state statutes against a supremacy clause challenge, 28 U.S.C. § 1257(2) (1982). The Supreme Court has recently heard several preemption cases on appeal. See, e.g., Goodyear Atomic Corp. v. Miller, 108 S.Ct. 1704, 1708 (1988); Fort Halifax Packing Co. v. Coyne, 107 S.Ct. 2211, 2214 (1987); Nantahala Power & Light Co. v. Thornburg, 476 U.S. 953, 962 (1986); Metropolitan Life Ins. Co. v. Massachusetts, 471 U.S. 724, 738 (1985). Congress recently elim- inated most of the Supreme Court's mandatory appellate jurisdiction. See Pub. L. No. 100- 352, 1988 U.S. CODE CONG. & ADMIN. NEWS 102 Stat. 662., 11. See, e.g., Exxon Corp. v. Eagerton, 462 U.S. 176 (1983); Blum v. Bacon, 457 U.S. 132, 137-38 (1982). The Court occasionally has given the impression of reaching out for the pre- emption issue even when the claim was not raised and considered below. See, e.g., Capital Cities Cable, Inc. v. Crigp, 467 U.S. 691, 697-98 (1994); Arkansas Elec. Coop. Corp. v. Arkan- sas Pub. Serv. Comm'n, 461 U.S. 375, 382 & n.6 (1983); Blum v. Bacon, 457 U.S. at 137 n.5. This practice enables the Court to avoid constitutional issues on which there is no consensus. See, e.g., Blum v. Bacon, 457 U.S at 146 (unanimous ruling on supremacy clause issue made moot claim that state program excluding recipients of Aid to Families with Dependent Chil- dren (AFDC) from receiving emergency cash assistance violated Equal Protection Clause). Compare Capital Cities Cable, Inc. v. Crisp, 467 U.S. 691 (1984) (unanimous resolution on preemption issue made moot question whether state statute prohibiting broadcast of liquor advertisements violated First Amendment) with Posadas de P.R. Assocs. v. Tourism Co., 106 S. Ct. 2968 (1986) (five-to-four split on whether Puerto Rico statute restricting advertising of casino gambling violated First Amendment). The Court's reliance on congressional willing- ness to overturn mistaken cases of statutory interpretation has been severely criticized in sev- eral contexts. See, e.j, Johnson v. Transportation Agency, 107 S. Ct. 1442, 1472-73 (1987) (Scalia, J., dissenting). See generally Kahn, Gramm-Rudman and the Capacity of Congress to Control the Future, 13 HASTINGS CONST. L.Q. 185, 211 (1986). 12. The cases usually contain some version of the following: It is well established that within constitutional limits Congress may preempt state authority by so stating in express terms. Absent explicit preemptive language, Con- gress' intent to supersede state law altogether may be found from a "'scheme of federal regulation... so pervasive as to-make reasonable the inference that Congress left no room for the States to supplement it,' because the 'Act of Congress may touch a field in which the federal interest is so dominant that the federal system willbe assumed to preclude enforcement of state laws on the same subject,' or because 'the object sought to be obtained by the federal law and the character of obligations im- posed by it may reveal the same purpose.'" Even where Congress has not entirely displaced state regulation in a specific area, state law is preempted to the extent that it actually conflicts with federal law. Such a conflict arises when "compliance with both federal and state regulations is a physical impossibility," or where state law "stands as an obstacle to the accomplishment and execution of the full purposes and objectives of Congress." Fall 19881 PREEMPTION AND FEDERALISM ' - Fall 19981 ries are useless in difficult cases. It is often. hard to determine which category governs a particular case. One-of the nation's eminent appellate judges recently wrote, "We are somewhat wary that these ready citations list, but do not describe, and catalog, but do not define,, any real distinc- tions among the various types of preemption." 3 The Supreme Court's failure to appreciate the link between preemp- tion and the Constitution is the chief cause of the defects in preemption doctrine. This Article explores ways in which that link might be re- stored. Part One examines the salient difficulties with the Supreme Court's current preemption jurisprudence. First, the Court's cases hold- ing that state laws must fall if Congress has"'occupied the field" of legis- lation have failed to provide courts with adequate guidance for determining whether a field has been occupied. Second, the Court's pro- nouncement that state laws must yield if they "stand as an obstacle" to a congressional objective is functionally indistinguishable from the Court's holding that state laws are ousted when Congress "occupies the field," although the Court treats the two rules as separate bases, for preemption. The "stands as an obstacle" test also forces the courts either to search quixotically for the "spirit" of a statute, or to choose'between two doctri- nally deficient theories of preemption, which I shall-call the "floor, not ceiling" theory and the "delicate balance" theory. Part Two discusses the roots of this dissonance in preemption, par- ticularly the Court's reluctance to consider preemption doctrine as. an aspect of constitutional law and its preference to treat preemption as an exercise in statutory interpretation. Part Two argues that preemption cases raise important questions about the nature of federalism under our Constitution and present delicate questions concerning the legislative Pacific Gas & Elee. Co. v. State Energy Resources Conservation & Dev. Comm'n, 461 U.S. 190, 203-04 (1983) (citations omitted). For other recent incantations of the test, see, California Coastal Comm'n v. Granite Rock Co., 107 S. Ct. 1419, 1425 (1987); International Paper Co. v. Ouellette, 107 S. Ct. 805, 811 (1987); California Fed. Say. & Loan Ass'n. v. Guerra, 107 S. Ct. 683, 689 (1987). Justice White listed four types of preemption in Pacific Gas & Electric: express preemp- tion, "leaving no room" preemption (known as "occupying the field" preemption in other cases), physical impossibility preemption, and obstacle preemption. But citing Pacific Gas & Electric in a later case, Justice White found only two general types of preemption, one with two subtypes.
Recommended publications
  • Integrating Preemption Threshold Scheduling and Dynamic Voltage Scaling for Energy Efficient Real-Time Systems

    Integrating Preemption Threshold Scheduling and Dynamic Voltage Scaling for Energy Efficient Real-Time Systems

    Integrating Preemption Threshold Scheduling and Dynamic Voltage Scaling for Energy Efficient Real-Time Systems Ravindra Jejurikar1 and Rajesh Gupta2 1 Centre for Embedded Computer Systems, University of California Irvine, Irvine CA 92697, USA jeÞÞ@cec׺ÙciºedÙ 2 Department of Computer Science and Engineering, University of California San Diego, La Jolla, CA 92093, USA gÙÔØa@c׺Ùc×dºedÙ Abstract. Preemption threshold scheduling (PTS) enables designing scalable real-time systems. PTS not only decreases the run-time overhead of the system, but can also be used to decrease the number of threads and the memory require- ments of the system. In this paper, we combine preemption threshold scheduling with dynamic voltage scaling to enable energy efficient scheduling in real-time systems. We consider scheduling with task priorities defined by the Earliest Dead- line First (EDF) policy. We present an algorithm to compute threshold preemption levels for tasks with given static slowdown factors. The proposed algorithm im- proves upon known algorithms in terms of time complexity. Experimental results show that preemption threshold scheduling reduces on an average 90% context switches, even in the presence of task slowdown. Further, we describe a dynamic slack reclamation technique that working in conjunction with PTS that yields on an average 10% additional energy savings. 1 Introduction With increasing mobility and proliferation of embedded systems, low power consump- tion is an important aspect of embedded systems design. Generally speaking, the pro- cessor consumes a significant portion of the total energy, primarily due to increased computational demands. Scaling the processor frequency and voltage based on the per- formance requirements can lead to considerable energy savings.
  • What Is an Operating System III 2.1 Compnents II an Operating System

    What Is an Operating System III 2.1 Compnents II an Operating System

    Page 1 of 6 What is an Operating System III 2.1 Compnents II An operating system (OS) is software that manages computer hardware and software resources and provides common services for computer programs. The operating system is an essential component of the system software in a computer system. Application programs usually require an operating system to function. Memory management Among other things, a multiprogramming operating system kernel must be responsible for managing all system memory which is currently in use by programs. This ensures that a program does not interfere with memory already in use by another program. Since programs time share, each program must have independent access to memory. Cooperative memory management, used by many early operating systems, assumes that all programs make voluntary use of the kernel's memory manager, and do not exceed their allocated memory. This system of memory management is almost never seen any more, since programs often contain bugs which can cause them to exceed their allocated memory. If a program fails, it may cause memory used by one or more other programs to be affected or overwritten. Malicious programs or viruses may purposefully alter another program's memory, or may affect the operation of the operating system itself. With cooperative memory management, it takes only one misbehaved program to crash the system. Memory protection enables the kernel to limit a process' access to the computer's memory. Various methods of memory protection exist, including memory segmentation and paging. All methods require some level of hardware support (such as the 80286 MMU), which doesn't exist in all computers.
  • Chapter 1. Origins of Mac OS X

    Chapter 1. Origins of Mac OS X

    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
  • A Hardware Preemptive Multitasking Mechanism Based on Scan-Path Register Structure for FPGA-Based Reconfigurable Systems

    A Hardware Preemptive Multitasking Mechanism Based on Scan-Path Register Structure for FPGA-Based Reconfigurable Systems

    A Hardware Preemptive Multitasking Mechanism Based on Scan-path Register Structure for FPGA-based Reconfigurable Systems S. Jovanovic, C. Tanougast and S. Weber Université Henri Poincaré, LIEN, 54506 Vandoeuvre lès Nancy, France [email protected] Abstract all the registers as well as all memories used in the circuit In this paper, we propose a hardware preemptive and to determine the starting point of the restoration multitasking mechanism which uses scan-path register process. On the other hand, the goal of the restoration is to structure and allows identifying the total task’s register restore the task’s context of processing as it was before its size for the FPGA-based reconfigurable systems. The interruption, in order to continue the execution previously main objective of this preemptive mechanism is to stopped. Several techniques allowing the hardware suspend hardware task having low priority, replace it by preemption are proposed in the literature. The pros and high-priority task and restart them at another time cons of mostly used approaches we will disscus in the (and/or from another area of the FPGA in FPGA-based following. designs). The main advantages of the proposed method The readback approach for context saving and storing are that it provides an attractive way for context saving of an outgoing task is one of the approaches which was and restoring of a hardware task without freezing other mostly used for the FPGA-based designs. No additional tasks during pre-emption phases and a small area hardware structures, simple implementation, no extra overhead. We show its feasibility by allowing us to design design efforts and no extra hardware consumption are the a simple computing example as well as the one of the most important advantages of this approach.
  • Preemptive Multitasking on Atmel® AVR® Microcontroller

    Preemptive Multitasking on Atmel® AVR® Microcontroller

    Advances in Information Science and Computer Engineering Preemptive Multitasking on Atmel® AVR® Microcontroller HABIBUR RAHMAN, Senthil Arumugam Muthukumaraswamy School of Engineering & Physical Sciences Heriot Watt University Dubai Campus Dubai International Academic City UNITED ARAB EMIRATES [email protected]; [email protected] Abstract: - This paper demonstrates the need for multitasking and scenario where multitasking is the only solution and how it can be achieved on an 8-bit AVR® microcontroller. This project explains how to create a simple kernel in a single C file, and execute any number of tasks in a multithreaded fashion. It first explains how the AVR® engine works and how it switches between different tasks using preemptive scheduling algorithm with the flexibility of blocking a task to allowing it more execution time based on their priority level. The code written for this project is basically in C, however the kernel code is mostly assembly functions called by C. The development environment is Atmel Studio®. The code is in such a way that it can be ported over any 8-bit AVR® microcontroller, however, this project demonstrates the results in both simulation and hardware chip on device Atmega8A. Key-Words: - AVR®, Microcontroller, Threading, Preemptive Scheduling, Multitasking. 1 Introduction architecture and will eventually lead to downloading Microcontroller development has been and compiling hundreds of files according to the exponential over the past two decades. Development provided operating system instructions and also in terms of speed, transistor density, multi-core spend time learning how to use it. embedding as well as number of peripheral subsystem on SoC(System on Chip) is common, and But if the user who has basic understanding of C development tools and compilers have been created language and very good understanding on that allows writing code for microcontroller on microcontroller wants to implement multitasking for higher level of abstraction layer an easy task.
  • UNIX History Page 1 Tuesday, December 10, 2002 7:02 PM

    UNIX History Page 1 Tuesday, December 10, 2002 7:02 PM

    UNIX History Page 1 Tuesday, December 10, 2002 7:02 PM CHAPTER 1 UNIX Evolution and Standardization This chapter introduces UNIX from a historical perspective, showing how the various UNIX versions have evolved over the years since the very first implementation in 1969 to the present day. The chapter also traces the history of the different attempts at standardization that have produced widely adopted standards such as POSIX and the Single UNIX Specification. The material presented here is not intended to document all of the UNIX variants, but rather describes the early UNIX implementations along with those companies and bodies that have had a major impact on the direction and evolution of UNIX. A Brief Walk through Time There are numerous events in the computer industry that have occurred since UNIX started life as a small project in Bell Labs in 1969. UNIX history has been largely influenced by Bell Labs’ Research Editions of UNIX, AT&T’s System V UNIX, Berkeley’s Software Distribution (BSD), and Sun Microsystems’ SunOS and Solaris operating systems. The following list shows the major events that have happened throughout the history of UNIX. Later sections describe some of these events in more detail. 1 UNIX History Page 2 Tuesday, December 10, 2002 7:02 PM 2 UNIX Filesystems—Evolution, Design, and Implementation 1969. Development on UNIX starts in AT&T’s Bell Labs. 1971. 1st Edition UNIX is released. 1973. 4th Edition UNIX is released. This is the first version of UNIX that had the kernel written in C. 1974. Ken Thompson and Dennis Ritchie publish their classic paper, “The UNIX Timesharing System” [RITC74].
  • Beyond Preemption:The Law and Policy of Intellectual Property

    Beyond Preemption:The Law and Policy of Intellectual Property

    Beyond Preemption:The Law and Policy of Intellectual Property Licensing Mark A. Lemley1† Table of Contents Introduction . I. The Tension Between Article 2B and Intellectual Property . A. Article 2B’s Expansion of the Scope and Power of Contracts . B. Potential Conflicts with Intellectual Property Law . 1. Patent Law . 2. Copyright Law . 3. Trade Secret Law . 4. Trademark Law . 5. Remedies . C. Conclusions . II. Preemption as a Partial Solution . A. The Nature of Intellectual Property Preemption . 1. The Basic Nature of Preemption . 2. Intellectual Property Preemption . a. Patent Law . b. Copyright Law . c. Applying Preemption to Contract Law . 1 Copyright © 1999 Mark A. Lemley and California Law Review, Inc. † Professor of Law, University of Texas School of Law; Visiting Professor of Law, Boalt Hall School of Law, University of California at Berkeley (Fall 1998); of counsel, Fish & Richardson P.C., Austin, Texas. I would like to thank Stephen Barnett, Julie Cohen, Richard Craswell, Robert Denicola, Rochelle Cooper Dreyfuss, Paul Goldstein, Robert Gomulkiewicz, Rose Hagan, Paul Heald, Dennis Karjala, Eric Lode, David McGowan, Charles McManis, Rob Merges, Maureen O’Rourke, Malla Pollack, Lloyd Weinreb, and participants in a faculty workshop at Stanford Law School and in the Berkeley Center for Law and Technology’s Conference on Article 2B of the Uniform Commercial Code for comments on an earlier draft. I would also like to thank Ryan Garcia and Sherri Shaw for research assistance. 111 CALIFORNIA LAW REVIEW [Vol. 87:111 B. The Limits of Preemption 1. Preemption Lacks Nuance . 2. Intellectual Property Rules Aren’t Always Statutory . 3. Intellectual Property Rules Aren’t Always Federal .
  • BIAS: Bluetooth Impersonation Attacks

    BIAS: Bluetooth Impersonation Attacks

    BIAS: Bluetooth Impersonation AttackS Daniele Antonioli Nils Ole Tippenhauer Kasper Rasmussen School of Computer and Communication Sciences CISPA Helmholtz Center Department of Computer Science EPFL for Information Security University of Oxford daniele.antonioli@epfl.ch [email protected] [email protected] Abstract—Bluetooth (BR/EDR) is a pervasive technology for subsequent secure connections. Two Bluetooth devices are wireless communication used by billions of devices. The Bluetooth expected to pair once and securely connect multiple times. standard includes a legacy authentication procedure and a secure During secure connection establishment the devices have to authentication procedure, allowing devices to authenticate to each other using a long term key. Those procedures are used authenticate the possession of the long term key that they have during pairing and secure connection establishment to prevent established while pairing. impersonation attacks. In this paper, we show that the Bluetooth In a recent paper, researchers showed that Bluetooth secure specification contains vulnerabilities enabling to perform imper- connection establishment is vulnerable to man-in-the-middle sonation attacks during secure connection establishment. Such attacks, even if the victims are already paired [4]. In that work vulnerabilities include the lack of mandatory mutual authenti- cation, overly permissive role switching, and an authentication however, the attack assumes that there is a legitimate secure procedure downgrade. We describe each vulnerability in detail, connection to break into. The attacker cannot target isolated and we exploit them to design, implement, and evaluate master Bluetooth devices, because the attacker cannot prove possession and slave impersonation attacks on both the legacy authentication of the victims’ long term key during secure connection procedure and the secure authentication procedure.
  • Precept 4: Multicore + Preemption

    Precept 4: Multicore + Preemption

    Precept 4: Multicore + Preemption COS 318: Fall 2017 Project 4 Schedule ● Precept: Monday 11/6, 7:30pm ○ (You are here) ● Design Review: Monday 11/13 ● Due: Sunday, 11/19, 11:55pm Precept Overview ● Adding multicore support ● Preemption ● Producer-Consumer problem ● Project specific topics Multicore Support Supporting “SMP” ● SMP: Symmetric Multiprocessing ○ All CPUs have equivalent access to resources ● Bootup: BSP initializes system + activate APs ● Each CPU has a core and a LAPIC ○ LAPIC: Performs interrupt routing and delivery Stack organization ● Each processor needs its own kernel stack ○ Different from stacks used by process’s kernel threads ○ Location specified by processor’s TSS ● We use “kernel bootstrap stacks” ○ Switch to process kernel stack after performing setup Multiprocessor OS: CPU State ● Must distinguish between global state and per-CPU state ● What state is private to a CPU? Multiprocessor OS: Locking ● We can now have multiple CPUs in the kernel at the same time ○ What if they write to the same kernel memory? ● Strawman approach: Big Kernel Lock ● Our approach: Fine grained locking Preemptive Scheduling Preemption: Clock interrupts ● Current OS: One process can hog CPU ○ Want to preempt processes after a timeout ● On timer interrupt: forcefully switch to another thread ○ Allows interleaving without explicit yields Preemption: Scheduling ● LAPIC can give us timer interrupts ○ Count number of milliseconds thread has run for ○ Yield once runtime > threshold ● Choose another thread to run ○ We use round-robin Preempting Kernel Execution Which part will be affected? ● Temporarily enable interrupts during the executions of sys_produce and sys_consume ● Leave other parts of the kernel unchanged; ● So only enable interrupts during these two functions.
  • Evaluating the Case for Regulation of Digital Platforms Giuseppe Colangelo*

    Evaluating the Case for Regulation of Digital Platforms Giuseppe Colangelo*

    Evaluating the Case for Regulation of Digital Platforms Giuseppe Colangelo* INTRODUCTION: THE CRISIS OF ANTITRUST IN THE DIGITAL ECONOMY Antitrust enforcement and competition policy in the digital economy is high on the agenda of authorities and policymakers. The flood of reports and policy papers recently released reflects the ongoing debate over the capability of current antitrust rules and tools to handle the emergence of large technology platforms (BigTechs) and to scrutinize their practices and business models. The distinctive features of digital markets apparently require a rethinking of the antitrust regime. The presence of strong economies of scale, extreme indirect network effects, remarkable economies of scope due the role of data as a critical input, and conglomerate effects, along with consumers’ behavioural biases and single-homing tendencies, represent significant barriers to entry that make digital markets highly concentrated, prone to tipping, and not easily contestable. Therefore, large incumbent players appear not to be under threat and hard to dislodge. Moreover, digital platforms act as gatekeepers (either by controlling the access of third-party firms to their users or controlling the consumption of products and services by their users) and regulators (due to their rule-setting role within their ecosystem), and frequently play a dual role, being simultaneously operators for the marketplace and sellers of their own products and services in competition with rival sellers. In light of this, mounting criticism against current competition policy allege that lax antitrust enforcement, flawed Judicial rules that reflect unsound economic theories or unsupported empirical claims, and the limited effectiveness of the antitrust toolkit have * Jean Monet Professor of EU Innovation Policy; Associate Professor of Law and Economics, University of Basilicata; TTLF Fellow, Stanford University and University of Vienna; giuseppe.colangelo1975 @gmail.com.
  • Multitasking and Real-Time Scheduling

    Multitasking and Real-Time Scheduling

    Multitasking and Real-time Scheduling EE8205: Embedded Computer Systems http://www.ee.ryerson.ca/~courses/ee8205/ Dr. Gul N. Khan http://www.ee.ryerson.ca/~gnkhan Electrical and Computer Engineering Ryerson University Overview • Processes/Tasks and Concurrency • Scheduling Priorities and Policies • Multitasking • Real-time Scheduling Fixed-Priority and Earliest Deadline First Scheduling • Sporadic and Aperiodic Process Scheduling Chapter 6 of the Text by Wayne Wolf, Chapter 13 of Text by Burns and Wellings © G. Khan Embedded Computer Systems–EE8205: Multitasking & Real-time Scheduling Page: 1 Introduction to Processes All multiprogramming operating systems are built around the concept of processes. Process is also called a task. OS and Processes • OS must interleave the execution of several processes to maximize CPU usage. Keeping reasonable/minimum response time • OS must allocate resources to processes. By avoiding deadlock • OS must also support: IPC: Inter-process communication Creation of processes by other processes © G. Khan Embedded Computer Systems–EE8205: Multitasking & Real-time Scheduling Page: 2 Task/Process Concept Serial Execution of Two Processes Interleaving the Execution of Process 1 and 2 © G. Khan Embedded Computer Systems–EE8205: Multitasking & Real-time Scheduling Page: 3 Processes and Managing Timing Complexity Multiple rates • multimedia • automotive Asynchronous Input • user interfaces • communication systems Engine Control Tasks Engine • spark control Controller • crankshaft sensing • fuel/air mixture • oxygen sensor • Kalman filter © G. Khan Embedded Computer Systems–EE8205: Multitasking & Real-time Scheduling Page: 4 Concurrency • Only one thread runs at a time while others are waiting. • Processor switches from one process to another so quickly that it appears all threads are running simultaneously.
  • COS 318: Operating Systems CPU Scheduling

    COS 318: Operating Systems CPU Scheduling

    COS 318: Operating Systems CPU Scheduling Jaswinder Pal Singh Computer Science Department Princeton University (http://www.cs.princeton.edu/courses/cos318/) Today’s Topics u CPU scheduling basics u CPU scheduling algorithms 2 When to Schedule? u Process/thread creation u Process/thread exit u Process thread blocks (on I/O, synchronization) u Interrupt (I/O, clock) 3 Preemptive and Non-Preemptive Scheduling Terminate Exited (call scheduler) Scheduler dispatch Running Block for resource (call scheduler) Yield, Interrupt (call scheduler) Ready Blocked Create Resource free, I/O completion interrupt (move to ready queue) 4 Scheduling Criteria u Assumptions l One process per user and one thread per process l Processes are independent u Goals for batch and interactive systems l Provide fairness l Everyone makes some progress; no one starves l Maximize CPU utilization • Not including idle process l Maximize throughput • Operations/second (min overhead, max resource utilization) l Minimize turnaround time • Batch jobs: time to execute (from submission to completion) l Shorten response time • Interactive jobs: time response (e.g. typing on a keyboard) l Proportionality • Meets user’s expectations Scheduling Criteria u Questions: l What are the goals for PCs versus servers? l Average response time vs. throughput l Average response time vs. fairness Problem Cases u Completely blind about job types l Little overlap between CPU and I/O u Optimization involves favoring jobs of type “A” over “B” l Lots of A’s? B’s starve u Interactive process trapped