first commit
This commit is contained in:
commit
d679edc5a5
5 changed files with 1102 additions and 0 deletions
3
README.md
Normal file
3
README.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
Some flashcards for 3303
|
||||
|
||||
import in mochi and use %%% as the seperator
|
||||
376
topic_10.md
Normal file
376
topic_10.md
Normal file
|
|
@ -0,0 +1,376 @@
|
|||
## What is the difference between the **Ready to Run** and **Running** states?
|
||||
|
||||
---
|
||||
|
||||
🚦
|
||||
|
||||
- **Ready to Run**: The thread is in the Runnable pool and waiting for a processor to become available.
|
||||
- **Running**: The thread's code is actively being executed by a processor.
|
||||
%%%
|
||||
How many threads can be in the **Running** state at any given time?
|
||||
|
||||
---
|
||||
|
||||
💻
|
||||
|
||||
- On a **single-processor** computer: At most **one** thread.
|
||||
- On a **multi-processor** computer: At most **one thread per processor**.
|
||||
%%%
|
||||
|
||||
## What operation moves a thread from the **Born** state to the **Runnable** state?
|
||||
|
||||
---
|
||||
|
||||
🐣 Invoking the **`start()`** method.
|
||||
%%%
|
||||
Define the following transitions between **Ready to Run** and **Running**:
|
||||
|
||||
1. **Dispatched**
|
||||
2. **Yield**
|
||||
3. **Preempted / Timeslice Expired**
|
||||
|
||||
---
|
||||
|
||||
🔄
|
||||
|
||||
1. **Dispatched**: The scheduler selects a "Ready" thread to start running.
|
||||
2. **Yield**: The thread voluntarily gives up the processor to let others run.
|
||||
3. **Preempted**: The OS forces the thread to stop running (often because its time is up or a higher priority thread arrived).
|
||||
%%%
|
||||
What does it mean to model a thread's lifecycle as a **Finite State Machine (FSM)**?
|
||||
|
||||
---
|
||||
|
||||
🤖 It means representing the various **states** a thread can occupy and the specific **operations** (transitions) that cause it to move from one state to another.
|
||||
%%%
|
||||
|
||||
## When does a thread transition into the **Dead** state?
|
||||
|
||||
💀 When its **`run()` method terminates**, either by returning normally or by throwing an **uncaught exception**.
|
||||
%%%
|
||||
What causes a thread to move into the **Sleeping** state, and how does it leave?
|
||||
|
||||
---
|
||||
|
||||
😴
|
||||
|
||||
- **Entering**: The thread invokes the **`sleep()`** method.
|
||||
- **Leaving**: It remains blocked until the specified **sleep time elapses** or it is interrupted.
|
||||
%%%
|
||||
|
||||
## How do the **`wait()`** and **`notify()`** methods interact?
|
||||
|
||||
---
|
||||
|
||||
🛑
|
||||
|
||||
- **`wait()`**: Causes the current thread to block and enter the **Waiting** state.
|
||||
- **`notify()` / `notifyAll()`**: Invoked by _another_ thread to move the waiting thread(s) back to the **Runnable** state.
|
||||
%%%
|
||||
What happens to a thread's state during an **I/O operation** (like reading a file)?
|
||||
|
||||
---
|
||||
|
||||
📥 The thread enters the **I/O blocked** state when the request is made and only becomes **Runnable** again once the **I/O is completed**.
|
||||
%%%
|
||||
|
||||
## If a method call (like `sleep` or `wait`) causes a thread to relinquish the processor, when does that method **return**?
|
||||
|
||||
---
|
||||
|
||||
⏳ The method does **not return** until the thread is rescheduled and is back in the **Running** state.
|
||||
%%%
|
||||
In what **context** are methods always executed?
|
||||
|
||||
---
|
||||
|
||||
🧵 Methods are always executed in the **invoking thread's context**. A thread can only invoke a method when it is currently in the **Running** state.
|
||||
%%%
|
||||
|
||||
## What are the three **named priority constants** defined in the Java Thread class?
|
||||
|
||||
---
|
||||
|
||||
1. **`Thread.MAX_PRIORITY`** (Value: 10)
|
||||
2. **`Thread.NORM_PRIORITY`** (Value: 5)
|
||||
3. **`Thread.MIN_PRIORITY`** (Value: 1)
|
||||
%%%
|
||||
What is the valid **integer range** for a thread's priority?
|
||||
|
||||
---
|
||||
|
||||
🔢 It must be an integer between **1 and 10**, inclusive.
|
||||
%%%
|
||||
How is a **newly created thread's** priority determined by default?
|
||||
|
||||
---
|
||||
|
||||
👪 It is set equal to the **priority of the thread that created it**.
|
||||
%%%
|
||||
Which methods are used to **modify or check** a thread's priority at runtime?
|
||||
|
||||
---
|
||||
|
||||
🛠️
|
||||
|
||||
- **`setPriority(int)`**: Sets the priority to a specific value.
|
||||
- **`getPriority()`**: Returns the current priority of the thread.
|
||||
%%%
|
||||
|
||||
## In a standard priority-based scheduler, which threads are **normally selected** to enter the Running state?
|
||||
|
||||
---
|
||||
|
||||
🚀 The threads in the **Runnable state with the highest priorities**.
|
||||
%%%
|
||||
|
||||
## What are three ways a thread **voluntarily** relinquishes the processor?
|
||||
|
||||
---
|
||||
|
||||
🙋
|
||||
|
||||
1. **`Thread.yield()`**: Explicitly giving up the processor.
|
||||
2. **`Thread.sleep()`**: Ceasing execution for a specific time.
|
||||
3. **`Object.wait()`**: Waiting for a notification from another thread.
|
||||
%%%
|
||||
What two events cause a thread to **terminate** and release the processor permanently?
|
||||
|
||||
---
|
||||
|
||||
🏁
|
||||
|
||||
1. The **`run()`** method finishes its execution.
|
||||
2. An **exception** is thrown that propagates beyond the `run()` method.
|
||||
%%%
|
||||
What is **Preemptive, Priority-Based Scheduling**?
|
||||
|
||||
---
|
||||
|
||||
🥊 A scheduling policy where a lower-priority thread is **forced to stop running** (preempted) as soon as a higher-priority thread becomes **ready to run**.
|
||||
|
||||
%%%
|
||||
How does a **timeslice** affect thread execution in supported systems?
|
||||
|
||||
---
|
||||
|
||||
⏳ If timeslicing is supported, a thread will relinquish the processor if its allotted **time interval (timeslice) expires**, allowing other threads of equal priority a chance to run.
|
||||
%%%
|
||||
Why does the JVM rely on the **preemption** of lower-priority threads?
|
||||
|
||||
---
|
||||
|
||||
🚨 To ensure that **high-priority threads** that need processor time urgently (e.g., for real-time tasks) receive it immediately without waiting for others to finish.
|
||||
%%%
|
||||
|
||||
## In a JVM without **timeslicing**, how do two equal-priority threads ($t_1$ and $t_2$) share a single processor?
|
||||
|
||||
---
|
||||
|
||||
🧵 $t_1$ will run until it **terminates, relinquishes the processor voluntarily, or is preempted** by a higher-priority thread. $t_2$ will not start until $t_1$ is no longer eligible to run.
|
||||
%%%
|
||||
How does **Timeslicing** change the execution of equal-priority threads?
|
||||
|
||||
---
|
||||
|
||||
🔄 The scheduler uses a **Round-Robin** approach, allowing each thread to run for a **fixed amount of time** before switching to the next thread of the same priority.
|
||||
%%%
|
||||
Does the Java specification **require** timeslicing for equal-priority threads?
|
||||
|
||||
---
|
||||
|
||||
📜 **No.** Either approach (running to completion or timeslicing) is permitted by the Java specification.
|
||||
%%%
|
||||
If $t_1$ and $t_2$ are high priority and $t_3$ is low priority, when will $t_3$ get to run in a timesliced system?
|
||||
|
||||
---
|
||||
|
||||
⏳ Only when **both $t_1$ and $t_2$** are no longer eligible to run (e.g., they terminate or block). The JVM will not schedule lower-priority threads while higher ones are Runnable.
|
||||
%%%
|
||||
|
||||
## What is **Bounded Priority Inversion**?
|
||||
|
||||
---
|
||||
|
||||
📉 It occurs when a **high-priority** thread is forced to wait for a **low-priority** thread to release a lock. It is "bounded" because the delay is limited to the time it takes the low-priority thread to finish its critical section.
|
||||
%%%
|
||||
|
||||
## How does **Unbounded Priority Inversion** differ from the bounded version?
|
||||
|
||||
---
|
||||
|
||||
🌪️ It happens when a **medium-priority** thread preempts the low-priority thread that holds the lock. Since the high-priority thread is waiting for the lock, and the low-priority thread can't run to release it because of the medium thread, the high-priority thread is blocked for an **indeterminate (unbounded)** amount of time.
|
||||
%%%
|
||||
|
||||
## Why is **disabling preemption** while a low-priority thread is in a critical section considered a poor solution?
|
||||
|
||||
🚫 Because it stops **all** other high-priority threads from running, even those that have **nothing to do** with the critical section or the lock in question.
|
||||
%%%
|
||||
What are the two common protocols used to solve the Priority Inversion problem?
|
||||
|
||||
---
|
||||
|
||||
🛡️
|
||||
|
||||
1. **Priority Inheritance Protocol**: The low-priority thread "inherits" the high-priority of the thread it is blocking until it releases the lock.
|
||||
2. **Priority Ceiling (Priority Protect) Protocol**: The priority of the thread holding the lock is elevated to a predefined "ceiling" value (the highest priority of any thread that might ever need that lock).
|
||||
%%%
|
||||
Which two system conditions must exist for **Unbounded Priority Inversion** to be a risk?
|
||||
|
||||
---
|
||||
|
||||
⚙️
|
||||
|
||||
1. **Priority-based preemptive scheduling**.
|
||||
2. A mechanism for **locking/mutual exclusion** to protect critical sections.
|
||||
%%%
|
||||
|
||||
## How does the **Priority Inheritance Protocol** protect against medium-priority threads?
|
||||
|
||||
---
|
||||
|
||||
🛡️ When a high-priority thread blocks on a lock held by a low-priority thread, the **low-priority thread's priority is raised** to match the high-priority thread. This prevents medium-priority threads from preempting it and causing unbounded delay.
|
||||
%%%
|
||||
|
||||
## When is a thread's priority **restored** to its original value under the Priority Inheritance Protocol?
|
||||
|
||||
---
|
||||
|
||||
🔙 As soon as the thread **leaves the critical section** and releases the lock.
|
||||
%%%
|
||||
What determines the **current priority** of a thread holding a lock under Priority Inheritance?
|
||||
|
||||
---
|
||||
|
||||
📈 It is the **higher** of:
|
||||
|
||||
1. Its own assigned priority.
|
||||
2. The priority of the **highest-priority thread** currently blocked and waiting for that same lock.
|
||||
%%%
|
||||
How does a **Deadlock** occur in a system with shared resources?
|
||||
|
||||
---
|
||||
|
||||
🔄 It arises when two or more threads are stuck in a circular wait: Thread A holds Resource 1 and waits for Resource 2, while Thread B holds Resource 2 and waits for Resource 1.
|
||||
|
||||
%%%
|
||||
What is the difference between **Deadlock Detection** and **Deadlock Prevention**?
|
||||
|
||||
---
|
||||
|
||||
🔍
|
||||
|
||||
- **Detection**: Allowing deadlocks to happen but using tools (like watchdog timers or request graph analysis) to find and reset the system.
|
||||
- **Prevention**: Using a strict policy, such as **requesting resources in the same order**, to ensure a deadlock can never physically occur.
|
||||
%%%
|
||||
Why is "requesting resources in the same order" considered a **Prevention** strategy?
|
||||
|
||||
---
|
||||
|
||||
📏 It removes the possibility of a **circular wait**. If everyone agrees to lock Resource A before Resource B, you can never have a situation where two threads are waiting on each other.
|
||||
%%%
|
||||
How does a **Watchdog Timer** help handle deadlocks?
|
||||
|
||||
---
|
||||
|
||||
🐕 It is a timer that must be reset periodically by the software; if a deadlock occurs and the software stops responding, the timer expires and **automatically resets the system**.
|
||||
%%%
|
||||
|
||||
## What is the **Ceiling Priority** of a lock?
|
||||
|
||||
---
|
||||
|
||||
🔝 It is a priority assigned to a lock when it is created that is **at least as high** as the priority of the highest-priority thread that can ever acquire it.
|
||||
%%%
|
||||
How does the **Priority Ceiling Protocol** handle preemption?
|
||||
|
||||
---
|
||||
|
||||
🛡️ Only threads with a priority **higher than the current global ceiling priority** can preempt a thread that is executing within a critical section.
|
||||
%%%
|
||||
|
||||
## How does PCP prevent **Deadlocks**?
|
||||
|
||||
---
|
||||
|
||||
🚫 By design, the protocol ensures the system is **deadlock-free** because it coordinates lock acquisition in a way that prevents circular wait conditions from ever forming.
|
||||
%%%
|
||||
In the Priority Ceiling Protocol, why might a high-priority thread be **blocked** even if a lock is free?
|
||||
|
||||
---
|
||||
|
||||
🚦 If the thread's priority is not higher than the **current global ceiling priority**, it is blocked from acquiring the lock to ensure that lower-priority threads currently holding other resources can finish without interference.
|
||||
%%%
|
||||
What are the main differences between **Priority Inheritance** and **Priority Ceiling** regarding configuration?
|
||||
|
||||
---
|
||||
|
||||
⚙️
|
||||
|
||||
- **Priority Inheritance**: Managed **transparently** by the system; no programmer setup is required.
|
||||
- **Priority Ceiling**: Requires the **programmer to manually configure** the priority ceilings for every lock.
|
||||
%%%
|
||||
How do the two protocols differ in when they "promote" a thread's priority?
|
||||
|
||||
---
|
||||
|
||||
📈
|
||||
|
||||
- **Priority Inheritance**: Promotion occurs **only when** a higher-priority thread actually attempts to acquire the lock.
|
||||
- **Priority Ceiling**: Promotion is associated with the **lock itself**; the priority is effectively managed as soon as any thread interacts with the protected critical section.
|
||||
%%%
|
||||
Does **Java** currently support the Priority Ceiling Protocol?
|
||||
|
||||
---
|
||||
|
||||
📜 **No.** The priority ceiling protocol is not currently supported by Java; Java implementations typically use Priority Inheritance.
|
||||
%%%
|
||||
|
||||
## What are **Green Threads**?
|
||||
|
||||
---
|
||||
|
||||
🌳 A thread model where the **JVM is completely responsible** for thread management (stack, PC, bookkeeping). The underlying operating system is **unaware** of these threads.
|
||||
%%%
|
||||
How does the OS view a Java process using **Green Threads**?
|
||||
|
||||
---
|
||||
|
||||
👁️ The OS sees the entire JVM as a **single process** with a single thread. All context switching between Java threads happens internally within the JVM without OS system calls.
|
||||
|
||||
%%%
|
||||
What are the scheduling characteristics of most **Green Thread** implementations?
|
||||
|
||||
---
|
||||
|
||||
⚖️ They typically support **priority-based, preemptive scheduling**, but most do **not** support timeslicing. They often use **priority inheritance** to prevent inversion.
|
||||
%%%
|
||||
What defines the **Native Threads** model?
|
||||
|
||||
---
|
||||
|
||||
🖥️ Java threads are mapped directly to the **threads supported by the host Operating System**. The OS, not the JVM, is responsible for scheduling the threads.
|
||||
%%%
|
||||
How are Java priorities handled in **Windows Native Threads**?
|
||||
|
||||
---
|
||||
|
||||
🗺️ There is a **one-to-one mapping** between Java and Win-32 threads, but because Windows has fewer priority levels, the **10 Java priorities are mapped onto 6 Win-32 priorities**.
|
||||
%%%
|
||||
Why might equal-priority threads behave differently on Windows vs. early Unix Green Threads?
|
||||
|
||||
---
|
||||
|
||||
⏳ In Windows Native Threads, equal-priority threads **timeslice**, whereas many Green Thread implementations do not support timeslicing (one runs until it blocks or terminates).
|
||||
%%%
|
||||
In **Embedded Systems**, how is Java thread scheduling typically determined?
|
||||
|
||||
---
|
||||
|
||||
📟 Java threads are usually mapped to the native threads/tasks of the **Real-Time Operating System (RTOS)**. Therefore, Java thread scheduling is equivalent to **RTOS scheduling**.
|
||||
%%%
|
||||
Why is **OS support (Native Threads)** required for true multi-processor concurrency?
|
||||
|
||||
---
|
||||
|
||||
🚀 Because Green Threads are managed inside a single OS process, they cannot be distributed across multiple physical CPUs by the OS. Only **Native Threads** allow the OS to run different Java threads on different cores simultaneously.
|
||||
233
topic_7.md
Normal file
233
topic_7.md
Normal file
|
|
@ -0,0 +1,233 @@
|
|||
## What is the primary role of a **Boundary Object**?
|
||||
|
||||
---
|
||||
|
||||
🌐 It defines **interfaces** to and communicates with the **external environment**.
|
||||
%%%
|
||||
What does a **Boundary Class** typically represent in a UML class diagram?
|
||||
|
||||
---
|
||||
|
||||
🖥️ It represents the **User Interface (UI)** or **external systems' interfaces**, depicting interactions between the system and its actors.
|
||||
%%%
|
||||
In terms of **External Interaction**, how does a Boundary Class function?
|
||||
|
||||
---
|
||||
|
||||
🔄 It acts as a **Proxy**: handling input/output operations and facilitating communication between the internal system and external entities.
|
||||
%%%
|
||||
What is the specific responsibility of a Boundary Object regarding **Hardware**?
|
||||
|
||||
---
|
||||
|
||||
🔌 **Device I/O**: It receives input from and/or sends output to a hardware device.
|
||||
%%%
|
||||
|
||||
## What are the **three key characteristics** of a Boundary Class?
|
||||
|
||||
---
|
||||
|
||||
1. **Interface Representation** (UI/External interfaces).
|
||||
2. **External Interaction (Proxy)** (Mediating communication).
|
||||
3. **Device I/O** (Hardware communication).
|
||||
%%%
|
||||
What is the primary function of an **Entity Object**?
|
||||
|
||||
---
|
||||
|
||||
📦 It **encapsulates information** and represents data that needs to be stored and managed within the system.
|
||||
%%%
|
||||
What are the two types of **Entity Objects** based on data lifespan?
|
||||
|
||||
---
|
||||
|
||||
⏳
|
||||
|
||||
1. **Data abstraction objects**: Used for **transient** data (temporary).
|
||||
2. **Database objects**: Used for **persistent** data (long-term).
|
||||
%%%
|
||||
In a UML class diagram, what do the **attributes** of an Entity Class represent?
|
||||
|
||||
---
|
||||
|
||||
📋 They represent the **properties or characteristics** of the entity, corresponding to specific data fields.
|
||||
%%%
|
||||
|
||||
## How do **Entity Classes** typically interact with one another?
|
||||
|
||||
---
|
||||
|
||||
🔗 Through **associations** (relationships) that indicate how different entities are connected.
|
||||
%%%
|
||||
If persistent data is stored in a database, what is the role of the **Entity Object**?
|
||||
|
||||
---
|
||||
|
||||
🎁 It acts as a **wrapper**: mapping database columns to the object's attributes.
|
||||
%%%
|
||||
Why is a **mutex** usually required when using Entity Objects in a multi-threaded environment?
|
||||
|
||||
---
|
||||
|
||||
🔒 Because Entity Objects are almost always **passive**, meaning they do not manage their own concurrency/execution flow.
|
||||
%%%
|
||||
What is the primary purpose of a **Control Object**?
|
||||
|
||||
---
|
||||
|
||||
🕹️ It provides **overall coordination** for a collection of objects within the system.
|
||||
%%%
|
||||
How do Control Objects facilitate the fulfillment of a **Use Case**?
|
||||
|
||||
---
|
||||
|
||||
🎼 They contain methods that **orchestrate the sequence of actions** needed to execute the use case logic.
|
||||
%%%
|
||||
|
||||
## How does a Control Object interact with **Boundary** and **Entity** classes?
|
||||
|
||||
---
|
||||
|
||||
🔄 It **receives input** from Boundary classes, processes it, and interacts with Entity classes to **retrieve or update** data.
|
||||
%%%
|
||||
What defines a **State-dependent** control object?
|
||||
|
||||
---
|
||||
|
||||
🚦 Its behavior depends on its **current state**, and it changes states based on **inputs (events)** from other objects.
|
||||
%%%
|
||||
What is a **Coordinator** control object?
|
||||
|
||||
---
|
||||
|
||||
🤝 An overall decision-making object that controls others but is **not state-dependent** (e.g., a system scheduler).
|
||||
%%%
|
||||
What is the function of a **Timer** control object?
|
||||
|
||||
---
|
||||
|
||||
⏱️ It controls other objects on a **periodic basis**, triggered by an external clock.
|
||||
%%%
|
||||
What are the **three types** of Control Objects?
|
||||
|
||||
---
|
||||
|
||||
1. **State-dependent** (Behavior depends on state).
|
||||
2. **Coordinator** (Decision making, non-state-based).
|
||||
3. **Timer** (Periodic triggers).
|
||||
%%%
|
||||
|
||||
## What is the primary role of **Application Logic** classes?
|
||||
|
||||
---
|
||||
|
||||
🧠 They encapsulate the **core functionality, algorithms, and logic** of an application, playing a central role in executing its operations.
|
||||
%%%
|
||||
How do Application Logic classes interact with **Entities** and **Controls**?
|
||||
|
||||
---
|
||||
|
||||
🔗 They interact with **Entity classes** to retrieve/update data and with **Control classes** to coordinate the flow of system activities.
|
||||
%%%
|
||||
|
||||
## What does it mean for Application Logic to be **independent of presentation details**?
|
||||
|
||||
---
|
||||
|
||||
🏗️ It ensures **separation of concerns**; changes to the User Interface (UI) should not directly impact the core application logic.
|
||||
%%%
|
||||
Why are Application Logic classes used to **partition logic away from data**?
|
||||
|
||||
---
|
||||
|
||||
🔄 Because **logic is expected to change** more frequently than the underlying data structures.
|
||||
%%%
|
||||
What is the difference between how **Simple** and **Complex Algorithms** are encapsulated?
|
||||
|
||||
---
|
||||
|
||||
🧮
|
||||
|
||||
- **Simple**: Often encapsulated directly within **Entity objects**.
|
||||
- **Complex**: Placed in a **separate class** that interacts with multiple objects (similar to a coordinator).
|
||||
%%%
|
||||
What is the purpose of a **Service** type Application Logic class?
|
||||
|
||||
---
|
||||
|
||||
🛠️ It provides a **specific service** to other objects, such as reading/writing data or forwarding messages across a network.
|
||||
%%%
|
||||
Which specific object type is the **only** one allowed to communicate with an **Actor**?
|
||||
|
||||
---
|
||||
|
||||
🎭 **Boundary Objects**. Actors cannot interact with Controllers or Entities directly.
|
||||
%%%
|
||||
What are the communication limits for a **Boundary Object**?
|
||||
|
||||
---
|
||||
|
||||
🔌 it can only talk to **Actors** and **Controllers**. (It cannot talk directly to Entities).
|
||||
%%%
|
||||
Who are **Entity Objects** permitted to communicate with?
|
||||
|
||||
---
|
||||
|
||||
📦 Only **Controllers** and **other Entity Objects**.
|
||||
%%%
|
||||
Which class acts as the "middleman" that can talk to **Boundary**, **Entity**, and other **Control** objects?
|
||||
|
||||
---
|
||||
|
||||
🕹️ The **Control** class. (Note: It still cannot talk directly to Actors).
|
||||
%%%
|
||||
Can an **Entity Object** initiate communication with a **Boundary Object**?
|
||||
|
||||
---
|
||||
|
||||
❌ **No.** Communication between data (Entity) and the interface (Boundary) must be mediated by a **Controller**.
|
||||
%%%
|
||||
Which object types are allowed to communicate with **others of their own type**?
|
||||
|
||||
---
|
||||
|
||||
👥 **Entity** objects and **Control** objects.
|
||||
%%%
|
||||
Why is a **Controller** forbidden from talking to an **Actor**?
|
||||
|
||||
---
|
||||
|
||||
🧱 To ensure **independence from presentation details**; the logic (Controller) should only interact with the interface representation (Boundary).
|
||||
%%%
|
||||
Which types of objects are assumed to be **active (concurrent)** by default?
|
||||
|
||||
---
|
||||
|
||||
🏃 **All non-entity objects**. Each has its own thread of control and can operate in parallel.
|
||||
%%%
|
||||
What does it mean for an **Entity Object** to be **passive**?
|
||||
|
||||
---
|
||||
|
||||
🧘 It does not have its own thread; instead, it is **called by active objects** to perform tasks.
|
||||
%%%
|
||||
How does communication differ between **Active** and **Passive** objects?
|
||||
|
||||
---
|
||||
|
||||
💬
|
||||
|
||||
- **Active to Active**: Asynchronous communication.
|
||||
- **Active to Passive**: Synchronous communication (e.g., a standard method call).
|
||||
%%%
|
||||
What is the primary purpose of a **Boundary Object** in the context of the Hardware/Software boundary?
|
||||
|
||||
---
|
||||
|
||||
🔌 To **abstract away the details** of communicating with the "hardware" side of the interface.
|
||||
%%%
|
||||
Why are **Entity Objects** usually the only passive objects in this architecture?
|
||||
|
||||
---
|
||||
|
||||
💾 Because their primary role is to **store and manage data** for other active components rather than orchestrating system behavior or timing.
|
||||
313
topic_8.md
Normal file
313
topic_8.md
Normal file
|
|
@ -0,0 +1,313 @@
|
|||
## What does the **Structural View** of a software architecture show?
|
||||
|
||||
---
|
||||
|
||||
🏗️ It is a **static view** (like a class diagram) that shows component types, ports, connectors, and architecture stereotypes.
|
||||
%%%
|
||||
What is the primary focus of the **Dynamic View** in software architecture?
|
||||
|
||||
---
|
||||
|
||||
🎬 It shows all possible **interactions** between objects in the system.
|
||||
%%%
|
||||
What does the **Deployment View** represent?
|
||||
|
||||
---
|
||||
|
||||
🌍 It shows the **physical configuration** of the system, including how software is mapped to hardware.
|
||||
%%%
|
||||
What are the defining characteristics of a **Sequential Software Architecture**?
|
||||
|
||||
---
|
||||
|
||||
🧵
|
||||
|
||||
1. **Single thread** of control.
|
||||
2. **All objects are passive**.
|
||||
3. Used by cyclic executives.
|
||||
%%%
|
||||
Name three major benefits of **Concurrent Software Architectures**.
|
||||
|
||||
---
|
||||
|
||||
🚀
|
||||
|
||||
1. Threads can run while others are **blocked** for events.
|
||||
2. Supports **multi-core** or distributed systems.
|
||||
3. Multiple input streams can be handled in **parallel**.
|
||||
%%%
|
||||
How do components in a **Component-Based Architecture** interact?
|
||||
|
||||
---
|
||||
|
||||
🔌 They are treated as **black boxes** that communicate through **well-defined interfaces**.
|
||||
%%%
|
||||
In a Component-Based system, what is a **Subsystem**?
|
||||
|
||||
---
|
||||
|
||||
🧩 A **Composite Component** (a component that contains other components).
|
||||
%%%
|
||||
|
||||
## When applying **Separation of Concerns**, what is the rule regarding objects on **separate nodes**?
|
||||
|
||||
---
|
||||
|
||||
🌐 They should be placed in **separate subsystems**.
|
||||
%%%
|
||||
Where should **Control objects** and the **Entity objects** they interact with be located?
|
||||
|
||||
---
|
||||
|
||||
📦 They should both be part of the **same subsystem**.
|
||||
%%%
|
||||
|
||||
## What is the rule for **Clients and Services** in subsystem structuring?
|
||||
|
||||
---
|
||||
|
||||
↔️ They should be in **separate subsystems**.
|
||||
%%%
|
||||
What are the defining features of a **Control Subsystem**?
|
||||
|
||||
---
|
||||
|
||||
🕹️
|
||||
|
||||
- Receives inputs from and sends outputs to the **external environment**.
|
||||
- It is usually **state-dependent**.
|
||||
- It interacts with other subsystems as needed.
|
||||
%%%
|
||||
What is the role of a **Coordinator Subsystem**?
|
||||
|
||||
---
|
||||
|
||||
🤝 It coordinates the actions of **multiple control subsystems** in a complex system.
|
||||
%%%
|
||||
What may a **User-Interaction Subsystem** contain for performance optimization?
|
||||
|
||||
---
|
||||
|
||||
🗄️ It may contain **Entity objects** for local storage and **caching**.
|
||||
%%%
|
||||
What is the difference between **Data Collection** and **Data Analysis** subsystems?
|
||||
|
||||
---
|
||||
|
||||
📊
|
||||
|
||||
- **Data Collection**: Gathers data from the environment and may perform **data reduction**.
|
||||
- **Data Analysis**: Provides **reports and analysis**; often operates in non-real-time.
|
||||
%%%
|
||||
How does a **Service Subsystem** differ from other subsystems in terms of behavior?
|
||||
|
||||
---
|
||||
|
||||
🛠️ It **does not initiate actions** on its own; it only provides services to other subsystems upon request.
|
||||
%%%
|
||||
What is the interface rule regarding **External Components**?
|
||||
|
||||
---
|
||||
|
||||
🔌 An external component should only interface to **one single subsystem**.
|
||||
%%%
|
||||
|
||||
## How does the scale of a **Design Pattern** compare to a single Class?
|
||||
|
||||
---
|
||||
|
||||
🏗️ It is a **larger-grained** form of reuse; it involves **multiple classes** and their specific interactions rather than just one.
|
||||
%%%
|
||||
What are **Idioms** in the context of software patterns?
|
||||
|
||||
---
|
||||
|
||||
💻 They are **low-level patterns** tailored to a **specific programming language**.
|
||||
%%%
|
||||
What is the difference between **Design Patterns** and **Architectural Patterns**?
|
||||
|
||||
---
|
||||
|
||||
📏
|
||||
|
||||
- **Design Patterns**: A small group of collaborating objects (e.g., Gang of Four).
|
||||
- **Architectural Patterns**: Larger-grained, addressing the structure of **major subsystems**.
|
||||
%%%
|
||||
What is a **Design Anti-Pattern**?
|
||||
|
||||
---
|
||||
|
||||
⚠️ **Bad code** or poor design solutions that are seen repeatedly.
|
||||
|
||||
%%%
|
||||
What is the difference between **Strict** and **Loose** Layered architectures?
|
||||
|
||||
---
|
||||
|
||||
🥞
|
||||
|
||||
- **Strict**: A layer can only use services from the layer **immediately below** it.
|
||||
- **Loose**: A layer can use services from **any** lower layer.
|
||||
%%%
|
||||
|
||||
## How does **Centralized Control** manage system inputs and outputs?
|
||||
|
||||
---
|
||||
|
||||
🎯 There is only **one control component**: all inputs flow into it, and all outputs originate from it (e.g., a Nuclear Power Station).
|
||||
%%%
|
||||
|
||||
## What defines **Distributed Collaborative Control**?
|
||||
|
||||
---
|
||||
|
||||
🤝 Multiple peer controllers manage subsets of the system and **exchange events** for coordination (e.g., Air Traffic Control).
|
||||
%%%
|
||||
|
||||
## What is the key restriction in **Distributed Independent Control**?
|
||||
|
||||
---
|
||||
|
||||
🧱 While control is distributed, there is **no communication** or coordination between the various control components (e.g., Railway crossings).
|
||||
%%%
|
||||
|
||||
## What characterizes a **Hierarchical Control** pattern?
|
||||
|
||||
---
|
||||
|
||||
👑 A **top-level coordinator** component sends commands to and receives responses from lower-level distributed controllers (e.g., a Telephone Switch).
|
||||
%%%
|
||||
In a **Master/Slave** pattern, what are the three main rules for the Slaves?
|
||||
|
||||
---
|
||||
|
||||
⛓️
|
||||
|
||||
1. Slaves **do not interact** with each other.
|
||||
2. Slaves **do not have** their own control objects.
|
||||
3. They only respond to the Master, who integrates their results.
|
||||
%%%
|
||||
|
||||
## What occurs in the **Synchronous Object Access** pattern?
|
||||
|
||||
---
|
||||
|
||||
🤝 Two or more **active objects** share data through a **passive object**. Because the data is shared, **mutual exclusion (mutex)** is strictly required.
|
||||
|
||||
%%%
|
||||
What is a classic example of the **Synchronous Object Access** pattern?
|
||||
|
||||
---
|
||||
|
||||
🏭 The **Producer-Consumer** problem (where both access a shared buffer entity).
|
||||
%%%
|
||||
How does the **Asynchronous Message Communication** pattern affect the sender?
|
||||
|
||||
---
|
||||
|
||||
📨 The sender (Producer) sends the message and **continues immediately** without waiting. Messages may queue at the consumer.
|
||||
|
||||
%%%
|
||||
What is a major risk of **Asynchronous Message Communication**?
|
||||
|
||||
---
|
||||
|
||||
⚠️ If the producer sends data faster than the consumer can receive it, **messages will be dropped** (buffer overflow).
|
||||
%%%
|
||||
How does **Bidirectional Asynchronous** messaging differ from standard asynchronous messaging?
|
||||
|
||||
---
|
||||
|
||||
🔄 The sender needs a reply but **not immediately**. Multiple messages can be sent before a response (like an ACK) is required.
|
||||
**Example:** TCP protocol.
|
||||
|
||||
%%%
|
||||
What happens to a client during a **Synchronous Message with Reply**?
|
||||
|
||||
---
|
||||
|
||||
🛑 The client sends a message and **blocks** (stops execution) until the server processes the request and sends a reply back.
|
||||
**Examples:** RPC (Remote Procedure Call) or RMI.
|
||||
|
||||
%%%
|
||||
In the **Asynchronous Message with Callback** pattern, what is the limit on outstanding requests?
|
||||
|
||||
---
|
||||
|
||||
📞 Only **one request** can be outstanding at a time. The client continues running but expects a response via a callback later.
|
||||
|
||||
%%%
|
||||
What is the primary benefit of the **Synchronous Message without Reply** pattern?
|
||||
|
||||
---
|
||||
|
||||
⏱️ It **throttles the producer**: the producer blocks until the consumer receives the message, preventing the producer from overwhelming a slow consumer.
|
||||
|
||||
---
|
||||
|
||||
## What is the main advantage and disadvantage of **Asynchronous Communication**?
|
||||
|
||||
⚖️
|
||||
|
||||
- **(+) More Parallelism**: The sender doesn't wait and keeps working.
|
||||
- **(-) Buffer Loss**: Data can be lost if the sender is faster than the receiver.
|
||||
%%%
|
||||
Why does **Synchronous Communication** involve less data copying on the same node?
|
||||
|
||||
---
|
||||
|
||||
📋 Because the sender and receiver can **share the same address space**, whereas asynchronous usually requires copying data into a message buffer and then out again.
|
||||
%%%
|
||||
Is the "reduced parallelism" of Synchronous Communication always a disadvantage?
|
||||
|
||||
---
|
||||
|
||||
🤔 **Not necessarily.** While it reduces parallel execution, the resulting "blocking" behavior naturally synchronizes the timing of the two components (throttling).
|
||||
%%%
|
||||
|
||||
## What are the two types of **Transparency** provided by a **Broker Pattern**?
|
||||
|
||||
---
|
||||
|
||||
🕵️
|
||||
|
||||
1. **Location Transparency**: The client only needs to know the broker's location; the server can move.
|
||||
2. **Platform Transparency**: The server can run on different hardware or software platforms.
|
||||
%%%
|
||||
|
||||
## In a **Broker Pattern**, what are the two ways a Broker can handle a client's request?
|
||||
|
||||
---
|
||||
|
||||
🔄
|
||||
|
||||
1. **Query once**: The broker provides the server's information, and the client contacts the server directly.
|
||||
2. **Intermediary**: The broker acts as a middleman and forwards the requests to the server.
|
||||
%%%
|
||||
What is the primary "cost" or disadvantage of using a **Broker**?
|
||||
|
||||
---
|
||||
|
||||
⏳ **Overhead**: The client must perform an extra step (asking the broker) before it can actually access the server.
|
||||
%%%
|
||||
What is the difference between **Broadcast** and **Subscription** message patterns?
|
||||
|
||||
---
|
||||
|
||||
📡
|
||||
|
||||
- **Broadcast**: Messages are sent to **everyone**; recipients must filter out what they don't want.
|
||||
- **Subscription**: Recipients **register** for specific messages; they only receive what they asked for.
|
||||
%%%
|
||||
|
||||
## Which well-known design pattern is used to implement **Subscription/Notification**?
|
||||
|
||||
---
|
||||
|
||||
🔔 The **Observer Pattern**: A publisher sends messages to a group without needing to know specific individual recipients.
|
||||
%%%
|
||||
What is the main downside of the **Broadcast** pattern in a network?
|
||||
|
||||
---
|
||||
|
||||
🚦 It creates **more message traffic**, as data is pushed to every potential recipient regardless of interest.
|
||||
177
topic_9.md
Normal file
177
topic_9.md
Normal file
|
|
@ -0,0 +1,177 @@
|
|||
## What is **Response Time** in the context of system performance?
|
||||
|
||||
---
|
||||
|
||||
⏱️ The duration from a **start event** (e.g., sending a request) to an **end event** (e.g., receiving the output).
|
||||
%%%
|
||||
How is **Throughput Capacity** defined?
|
||||
|
||||
---
|
||||
|
||||
🚀 The **maximum allowed frequency** of responses. Note that these may overlap in time, such as in web servers handling multiple clients.
|
||||
%%%
|
||||
|
||||
## What does the **Utilization** of a resource measure?
|
||||
|
||||
---
|
||||
|
||||
📉 The **percentage of time** a resource remains in a "busy" state versus an "idle" state.
|
||||
%%%
|
||||
What is the difference between a **delay measure** and a **deadline** in embedded systems?
|
||||
|
||||
---
|
||||
|
||||
📐
|
||||
|
||||
- **Delay measure**: The actual measured time between stimulus and response.
|
||||
- **Deadline**: The **maximum allowed delay** the system can tolerate.
|
||||
%%%
|
||||
When measuring by events, what does **"Wall Clock Time"** refer to?
|
||||
|
||||
---
|
||||
|
||||
⌚ The actual time elapsed as measured by a **system timer** or stopwatch, including execution, transfer latency, and waiting (queuing).
|
||||
%%%
|
||||
What are the standard components of an **Event Log** entry?
|
||||
|
||||
---
|
||||
|
||||
📝 `[time, entity, event code, ...additional data]`
|
||||
%%%
|
||||
How do you calculate **Throughput** using event counters?
|
||||
|
||||
---
|
||||
|
||||
🧮 By taking the **total count** of events and **dividing it by the duration** of the measurement period.
|
||||
%%%
|
||||
|
||||
## What are the **two methods** for measuring the state of an entity (e.g., "Device Busy")?
|
||||
|
||||
---
|
||||
|
||||
1. **Event Logging**: Record when it "goes busy" and "goes idle," then sum the total time.
|
||||
2. **Sampling**: Use a **timer-based daemon** to periodically check the state and count how often it is busy vs idle.
|
||||
%%%
|
||||
|
||||
## What is a major limitation of **Processor-level** measurements?
|
||||
|
||||
---
|
||||
|
||||
🚫 There is **no application context**. While you can see cache misses or % busy time, you cannot identify which specific application function is responsible for the delay.
|
||||
%%%
|
||||
|
||||
How does the OS distinguish between a **Process** and a **Thread**?
|
||||
|
||||
---
|
||||
|
||||
🧵
|
||||
|
||||
- **Thread**: A single thread of control/execution.
|
||||
- **Process**: A collection of threads and an associated **address space**.
|
||||
%%%
|
||||
|
||||
## How does the **OS Scheduler** view the population of threads?
|
||||
|
||||
---
|
||||
|
||||
🎟️ It sees them as **tokens** moving through various states (e.g., Ready, Running, Waiting, Dead) and managed within queues.
|
||||
%%%
|
||||
What is the difference between **System Threads** and **User Threads**?
|
||||
|
||||
---
|
||||
|
||||
👥
|
||||
|
||||
- **User Threads**: Run the actual application and middleware logic.
|
||||
- **System Threads**: Run OS services and the scheduler itself (there may be hundreds of these).
|
||||
%%%
|
||||
In UNIX accounting, what two categories is **Process CPU time** divided into?
|
||||
|
||||
---
|
||||
|
||||
⏰
|
||||
|
||||
1. **System Time**: Time spent executing OS/kernel-level calls.
|
||||
2. **User Time**: Time spent executing the application's own code.
|
||||
%%%
|
||||
What types of operations are measured at the **OS Service Level**?
|
||||
|
||||
---
|
||||
|
||||
💾 Disk I/O, memory usage, and network operations (packets sent/received).
|
||||
%%%
|
||||
What is the "granularity" of **Network measurements** compared to **Disk/Memory**?
|
||||
|
||||
---
|
||||
|
||||
🔍
|
||||
|
||||
- **Disk/Memory**: Can often be tracked with granularity down to the specific **thread**.
|
||||
- **Network**: Usually measured for the **system as a whole**.
|
||||
%%%
|
||||
What "exotic" tool can be used to record specific event times by thread at the OS level?
|
||||
|
||||
---
|
||||
|
||||
🕵️ **OS Tracing Tools**.
|
||||
%%%
|
||||
|
||||
## How does a **Sampling Profiler** determine where a program is spending its time?
|
||||
|
||||
---
|
||||
|
||||
📉 It **periodically samples the instruction counter** and uses a symbol table to map those instructions to specific methods or procedures. The percentage of total counts per method represents the percentage of time spent there.
|
||||
%%%
|
||||
What is the purpose of **Stack Sampling** in profiling?
|
||||
|
||||
---
|
||||
|
||||
🌳 It captures the **context of the call** by recording the sequence of calling methods (the call tree), allowing the profiler to break down time spent in higher-level methods into their constituent lower-level calls.
|
||||
%%%
|
||||
|
||||
## What are the **three major steps** in the Measurement Technique process?
|
||||
|
||||
---
|
||||
|
||||
1. **Specify**: Decide exactly what you want to measure.
|
||||
2. **Instrument/Gather**: Attach monitors and run a benchmark to collect data.
|
||||
3. **Analyze/Transform**: Process the raw data into meaningful insights.
|
||||
%%%
|
||||
What is the primary objective when choosing a **Measurement Tool**?
|
||||
|
||||
---
|
||||
|
||||
🎯 To measure the behavior of the system **without perturbing it** (avoiding the "observer effect" where the tool itself slows down the system enough to change the results).
|
||||
%%%
|
||||
Compare the two main **Monitoring Modes**: Event Trace vs. Sampling.
|
||||
|
||||
---
|
||||
|
||||
🔄
|
||||
|
||||
- **Event Trace**: Collects info on specific **state changes** via probes; has low overhead (~5%) but shouldn't be used in sensitive areas like interrupt handlers.
|
||||
- **Sampling**: **Polls the system state** periodically; accuracy is proportional to overhead (higher accuracy requires more frequent polling).
|
||||
%%%
|
||||
What are the pros and cons of **Hardware Monitors** (e.g., oscilloscopes or logic analyzers)?
|
||||
|
||||
---
|
||||
|
||||
🔌
|
||||
|
||||
- **(+)**: External to the system, so they **don't perturb** results; very portable.
|
||||
- **(-)**: Hard to use and difficult to map a raw electrical event back to a specific software cause.
|
||||
%%%
|
||||
What is the difference between the two types of **Software Monitors**?
|
||||
|
||||
---
|
||||
|
||||
🖥️
|
||||
|
||||
1. **Accounting Systems** (e.g., `sar`): Used for billing/resource usage; may not collect enough specific data for debugging.
|
||||
2. **Program Analyzers** (e.g., Valgrind, JProfiler): Provide deep code insights but can **significantly interfere** with system performance.
|
||||
%%%
|
||||
How does a **Hybrid Monitor** function?
|
||||
|
||||
---
|
||||
|
||||
🤝 It combines both worlds: **event signals** are embedded in the software, but they are processed by an **external hardware device** to minimize system perturbation.
|
||||
Loading…
Add table
Add a link
Reference in a new issue