diff --git a/README.en.md b/README.en.md index 41bdc6e..e3cfdaf 100644 --- a/README.en.md +++ b/README.en.md @@ -64,10 +64,10 @@ docker compose up ## 🎮 How to use -1. **Create your processes**: In the left panel, add processes by defining name, arrival time, priority, and a sequence of bursts (CPU and I/O). Or use the random generator to get started quickly. -2. **Configure the scheduler**: Choose an algorithm and adjust the parameters (quantum for RR, aging for Priority, etc.). +1. **Create your processes**: In the left panel, add processes by defining name, arrival time, priority, and a sequence of bursts (CPU and I/O). Enable the **Use Threads** toggle to create threads within a process, choosing the model (MANY_TO_ONE, ONE_TO_ONE, or MANY_TO_MANY) and the intra-process policy (FCFS, RR, or Priority). +2. **Configure the scheduler**: Choose an algorithm and adjust the parameters (quantum for RR, aging for Priority, quantums and boost interval for MLFQ, etc.). 3. **Run the simulation**: Use the Play/Pause/Step controls to run the simulation at the speed you want (0.25× to 4×). -4. **Analyze the results**: The Gantt chart shows each process's state in real time. At the end, the metrics panel displays turnaround, waiting time, throughput, and more. +4. **Analyze the results**: The Gantt chart shows each process's state in real time (and its threads, when configured). At the end, the metrics panel displays turnaround, waiting time, throughput, and — in the Threads tab — individual per-thread metrics. > 💡 **Tip:** Load one of the built-in **presets** to see classic phenomena such as the FCFS convoy effect or priority starvation. @@ -83,8 +83,10 @@ docker compose up | **Round Robin (RR)** | ✅ | Quantum | | **Priority NP**: Non-Preemptive Priority | ❌ | Aging (optional) | | **Priority P**: Preemptive Priority | ✅ | Aging (optional) | +| **Priority RR**: Priority with Round Robin | ✅ | Quantum + Aging (optional) | | **HRRN**: Highest Response Ratio Next | ❌ | None | | **Multilevel Queue** | ✅ | Quantum per queue | +| **MLFQ**: Multilevel Feedback Queue | ✅ | Quantums per queue + boost interval | > See the [algorithms documentation](./docs/algorithms.en.md) for details on how each one works. @@ -119,20 +121,30 @@ src/ │ │ ├── priority_rr.ts │ │ ├── hrrn.ts │ │ ├── multilevel.ts +│ │ ├── mlfq.ts # Multilevel Feedback Queue │ │ └── index.ts # Dispatch by algorithm -│ ├── engine.ts # SimulationEngine, orchestrates the ticks -│ ├── metrics.ts # Per-process and global metrics computation +│ ├── engine.ts # SimulationEngine, orchestrates the ticks (thread-aware) +│ ├── thread-scheduler.ts # Intra-process scheduler (FCFS / RR / Priority) +│ ├── metrics.ts # Per-process, global, and per-thread metrics computation │ ├── types.ts # All TypeScript interfaces -│ └── presets.ts # Pre-defined scenarios +│ └── presets.ts # Pre-defined scenarios (processes and threads) │ ├── store/ # Global state with Zustand ├── components/ # React components │ ├── ProcessPanel/ # Process creation and editing +│ │ ├── ThreadEditor.tsx # Thread editor (model, policy, per-thread bursts) +│ │ └── ... │ ├── SchedulerPanel/ # Algorithm selection and parameters │ ├── ControlBar/ # Play, Pause, Step, Reset, speed │ ├── GanttChart/ # Interactive Gantt chart +│ │ ├── GanttThreadRow.tsx # Thread sub-row in the Gantt chart +│ │ └── ... │ ├── MetricsPanel/ # Table, charts, and global metrics +│ │ ├── ThreadMetricsTable.tsx # Per-thread metrics table +│ │ └── ... │ └── shared/ # Buttons, badges, tooltips, modals +│ ├── threadUtils.ts # Thread color derivation (HSL) +│ └── ... │ └── hooks/ # Custom hooks (animation loop, export, etc.) ``` @@ -143,6 +155,8 @@ src/ Load classic scenarios with a single click to explore OS phenomena: +**Processes:** + | Preset | What it demonstrates | |--------|----------------------| | `classic_fcfs` | Basic execution with FCFS, no I/O | @@ -153,6 +167,16 @@ Load classic scenarios with a single click to explore OS phenomena: | `io_heavy` | Mix of CPU Bound vs. I/O Bound processes | | `multilevel_demo` | Multiple queues with different priorities | +**Threads:** + +| Preset | What it demonstrates | +|--------|----------------------| +| `many_to_one` | N:1 model — any thread's I/O blocks the entire process | +| `one_to_one` | 1:1 model — threads block independently | +| `many_to_many` | N:M model — kernel slots limit parallelism | +| `thread_starvation` | Intra-process starvation with Priority policy | +| `threads_vs_processes` | Direct comparison: threaded process vs single-burst process | + --- ## 🧪 Tests diff --git a/README.md b/README.md index 1db056f..87f4307 100644 --- a/README.md +++ b/README.md @@ -62,10 +62,10 @@ docker compose up ## 🎮 Como usar -1. **Crie seus processos**: No painel esquerdo, adicione processos definindo nome, tempo de chegada, prioridade e sequência de bursts (CPU e I/O). Ou use o gerador aleatório para começar rápido. -2. **Configure o escalonador**: Escolha o algoritmo e ajuste os parâmetros (quantum para RR, aging para Priority, etc.). +1. **Crie seus processos**: No painel esquerdo, adicione processos definindo nome, tempo de chegada, prioridade e sequência de bursts (CPU e I/O). Ative a opção **Usar Threads** para criar threads dentro do processo, escolhendo o modelo (MANY_TO_ONE, ONE_TO_ONE ou MANY_TO_MANY) e a política intra-processo (FCFS, RR ou Priority). +2. **Configure o escalonador**: Escolha o algoritmo e ajuste os parâmetros (quantum para RR, aging para Priority, quantuns e boost para MLFQ, etc.). 3. **Execute a simulação**: Use os controles de Play/Pause/Step para rodar a simulação na velocidade que quiser (0.25× até 4×). -4. **Analise os resultados**: O diagrama de Gantt mostra em tempo real o estado de cada processo. Ao final, o painel de métricas exibe turnaround, waiting time, throughput e mais. +4. **Analise os resultados**: O diagrama de Gantt mostra em tempo real o estado de cada processo (e suas threads, quando configuradas). Ao final, o painel de métricas exibe turnaround, waiting time, throughput, e — na aba Threads — métricas individuais por thread. > 💡 **Dica:** Carregue um dos **presets** disponíveis para ver fenômenos clássicos como o efeito de comboio do FCFS ou starvation com Priority Scheduling. @@ -81,8 +81,10 @@ docker compose up | **Round Robin (RR)** | ✅ | Quantum | | **Priority NP**: Prioridade Não-Preemptiva | ❌ | Aging (opcional) | | **Priority P**: Prioridade Preemptiva | ✅ | Aging (opcional) | +| **Priority RR**: Prioridade com Round Robin | ✅ | Quantum + Aging (opcional) | | **HRRN**: Highest Response Ratio Next | ❌ | Nenhum | | **Multilevel Queue** | ✅ | Quantum por fila | +| **MLFQ**: Multilevel Feedback Queue | ✅ | Quantuns por fila + intervalo de boost | > Consulte a [documentação dos algoritmos](./docs/algorithms.md) para detalhes sobre como cada um funciona. @@ -117,20 +119,30 @@ src/ │ │ ├── priority_rr.ts │ │ ├── hrrn.ts │ │ ├── multilevel.ts +│ │ ├── mlfq.ts # Multilevel Feedback Queue │ │ └── index.ts # Dispatch por algoritmo -│ ├── engine.ts # SimulationEngine, orquestra os ticks -│ ├── metrics.ts # Cálculo de métricas por processo e globais +│ ├── engine.ts # SimulationEngine, orquestra os ticks (suporte a threads) +│ ├── thread-scheduler.ts # Escalonador intra-processo (FCFS / RR / Priority) +│ ├── metrics.ts # Cálculo de métricas por processo, globais e por thread │ ├── types.ts # Todas as interfaces TypeScript -│ └── presets.ts # Cenários pré-definidos +│ └── presets.ts # Cenários pré-definidos (processos e threads) │ ├── store/ # Estado global com Zustand ├── components/ # Componentes React │ ├── ProcessPanel/ # Criação e edição de processos +│ │ ├── ThreadEditor.tsx # Editor de threads (modelo, política, bursts por thread) +│ │ └── ... │ ├── SchedulerPanel/ # Seleção de algoritmo e parâmetros │ ├── ControlBar/ # Play, Pause, Step, Reset, velocidade │ ├── GanttChart/ # Diagrama de Gantt interativo +│ │ ├── GanttThreadRow.tsx # Sub-linha de thread no Gantt +│ │ └── ... │ ├── MetricsPanel/ # Tabela, gráficos e métricas globais +│ │ ├── ThreadMetricsTable.tsx # Tabela de métricas por thread +│ │ └── ... │ └── shared/ # Botões, badges, tooltips, modais +│ ├── threadUtils.ts # Derivação de cores de threads (HSL) +│ └── ... │ └── hooks/ # Hooks personalizados (loop de animação, export, etc.) ``` @@ -141,6 +153,8 @@ src/ Carregue cenários clássicos com um clique para explorar fenômenos de SO: +**Processos:** + | Preset | O que demonstra | |--------|-----------------| | `classic_fcfs` | Execução básica com FCFS, sem I/O | @@ -151,6 +165,16 @@ Carregue cenários clássicos com um clique para explorar fenômenos de SO: | `io_heavy` | Mix de processos CPU Bound vs I/O Bound | | `multilevel_demo` | Múltiplas filas com prioridades diferentes | +**Threads:** + +| Preset | O que demonstra | +|--------|-----------------| +| `many_to_one` | Modelo N:1 — I/O de uma thread bloqueia todo o processo | +| `one_to_one` | Modelo 1:1 — threads bloqueiam independentemente | +| `many_to_many` | Modelo N:M — slots de kernel limitam o paralelismo | +| `thread_starvation` | Starvation intra-processo com política Priority | +| `threads_vs_processes` | Comparação direta: processo com threads vs processo único | + --- ## 🧪 Testes diff --git a/dist.tar.gz b/dist.tar.gz index e051a69..2c461ab 100644 Binary files a/dist.tar.gz and b/dist.tar.gz differ diff --git a/docs/algorithms.en.md b/docs/algorithms.en.md index 6f994b4..2f2c063 100644 --- a/docs/algorithms.en.md +++ b/docs/algorithms.en.md @@ -147,7 +147,7 @@ The process with the **highest ratio** is selected. This naturally increases the ## Multilevel Queue -**Type:** Preemptive +**Type:** Preemptive **Parameters:** number of queues, quantum per queue ### How it works @@ -158,6 +158,106 @@ This allows different classes of processes to be treated distinctly: for example --- +## MLFQ (Multilevel Feedback Queue) + +**Type:** Preemptive +**Parameters:** number of queues, quantum per queue (default: [2, 4, 8]), boost interval + +### How it works + +MLFQ is an extension of the Multilevel Queue that allows **processes to move between queues** based on their observed runtime behavior — eliminating the need to know burst durations in advance. + +#### Movement rules + +| Event | Action | +|-------|--------| +| Newly arrived process | Enters **queue 0** (highest priority) | +| Process exhausts the quantum of its current queue | **Demoted** to the next queue (lower priority) | +| Process returns from I/O | Stays in the **same queue** (cooperative behavior is rewarded) | +| Boost tick (configurable interval) | **All** processes are moved to queue 0 | + +#### Why is MLFQ efficient? + +- Interactive processes (I/O Bound) naturally stay in high-priority queues because they leave the CPU before exhausting the quantum. +- Batch processes (CPU Bound) progressively migrate to lower-priority queues where they receive larger quantums. +- The periodic boost prevents starvation: even processes that fell to lower queues eventually return to the top. + +#### Example with 3 queues (quantums: 2, 4, 8) + +``` +Process A (CPU Bound, burst=12): + Queue 0 → uses 2 ticks, demoted → Queue 1 + Queue 1 → uses 4 ticks, demoted → Queue 2 + Queue 2 → uses remaining 6 ticks (quantum=8, not exhausted) + +Process B (I/O Bound, burst=1 CPU + I/O + burst=1 CPU): + Queue 0 → uses 1 tick → goes to I/O → returns to Queue 0 + → always stays in the highest-priority queue +``` + +### Parameters + +| Parameter | Default | Description | +|-----------|---------|-------------| +| Number of queues | 3 | Number of priority queues | +| Quantum per queue | [2, 4, 8] | Time slice for each queue | +| Boost interval | 20 ticks | Every N ticks, all processes move up to queue 0 | + +--- + +## Thread Models + +PSS supports **thread** simulation within processes, implementing the three classical models described in Operating Systems textbooks. + +### General Concepts + +- A process can have **N user threads**, each with its own burst sequence (CPU and I/O). +- The scheduling policy among threads within the same process is configurable: **FCFS**, **Round Robin**, or **Priority**. +- The thread model determines how user threads map to kernel threads. + +### MANY_TO_ONE (N:1) + +**N user threads → 1 kernel thread** + +- Only one thread can use the CPU at a time within the process. +- If any thread initiates I/O, **the entire process blocks** (the kernel thread is stuck). +- No real parallelism; very simple to implement. +- Simulated by the `many_to_one` presets. + +### ONE_TO_ONE (1:1) + +**Each user thread → 1 dedicated kernel thread** + +- Threads block **independently**: if Thread A does I/O, Threads B and C remain in the Ready queue. +- The process only terminates when **all** threads have terminated. +- The process blocks only when all threads are simultaneously in I/O. +- Simulated by the `one_to_one` presets. + +### MANY_TO_MANY (N:M) + +**N user threads → M kernel threads (M ≤ N)** + +- The number of kernel threads (`kernelThreadCount`) is configurable. +- If all M kernel slots are occupied, additional user threads wait in the **kernel wait queue** (`KernelWait`). +- Combines flexibility with resource control: more active threads than N:1 but less overhead than 1:1. +- Simulated by the `many_to_many` presets. + +### Intra-Process Policy + +Defines how the scheduler selects the next thread when multiple threads are Ready within the same process: + +| Policy | Behavior | +|--------|----------| +| **FCFS** | The oldest thread in the Ready queue is selected | +| **Round Robin (RR)** | Each thread receives `threadQuantum` ticks; when exhausted, it goes to the end of the queue | +| **Priority** | The highest-priority thread is selected; immediate preemption if a higher-priority thread becomes ready | + +### Gantt Chart with Threads + +When a process has threads, the Gantt chart displays **sub-rows** below the process row, one per thread, with colors derived from the process color (40° hue shift per thread). The state of each thread (New, Ready, Running, Waiting, Terminated) is colored using the same CSS variables as process states. + +--- + ## References - Silberschatz, A., Galvin, P. B., & Gagne, G., *Operating System Concepts*, 10th edition. diff --git a/docs/algorithms.md b/docs/algorithms.md index bf87831..d84ef76 100644 --- a/docs/algorithms.md +++ b/docs/algorithms.md @@ -147,7 +147,7 @@ O processo com o **maior ratio** é selecionado. Isso faz com que processos que ## Multilevel Queue -**Tipo:** Preemptivo +**Tipo:** Preemptivo **Parâmetros:** número de filas, quantum por fila ### Como funciona @@ -158,6 +158,106 @@ Isso permite tratar diferentes classes de processos de forma distinta: por exemp --- +## MLFQ (Multilevel Feedback Queue) + +**Tipo:** Preemptivo +**Parâmetros:** número de filas, quantum por fila (padrão: [2, 4, 8]), intervalo de boost + +### Como funciona + +O MLFQ é uma extensão do Multilevel Queue que permite **mover processos entre filas** com base em seu comportamento observado em tempo de execução — eliminando a necessidade de conhecer os bursts antecipadamente. + +#### Regras de movimentação + +| Evento | Ação | +|--------|------| +| Processo recém-chegado | Entra na **fila 0** (maior prioridade) | +| Processo esgota o quantum da fila atual | **Rebaixado** para a fila seguinte (menor prioridade) | +| Processo retorna do I/O | Permanece na **mesma fila** (comportamento cooperativo é recompensado) | +| Tick de boost (intervalo configurável) | **Todos** os processos são movidos para a fila 0 | + +#### Por que o MLFQ é eficiente? + +- Processos interativos (I/O Bound) naturalmente ficam nas filas de alta prioridade porque abandonam a CPU antes de esgotar o quantum. +- Processos batch (CPU Bound) migram progressivamente para filas de baixa prioridade onde recebem quantuns maiores. +- O boost periódico evita starvation: mesmo processos que caíram para as filas inferiores eventualmente retornam ao topo. + +#### Exemplo com 3 filas (quantuns: 2, 4, 8) + +``` +Processo A (CPU Bound, burst=12): + Fila 0 → usa 2 ticks, rebaixado → Fila 1 + Fila 1 → usa 4 ticks, rebaixado → Fila 2 + Fila 2 → usa 6 ticks restantes (quantum=8, não esgota) + +Processo B (I/O Bound, burst=1 CPU + I/O + burst=1 CPU): + Fila 0 → usa 1 tick → vai para I/O → retorna à Fila 0 + → sempre permanece na fila de maior prioridade +``` + +### Parâmetros + +| Parâmetro | Padrão | Descrição | +|-----------|--------|-----------| +| Número de filas | 3 | Quantidade de filas de prioridade | +| Quantuns por fila | [2, 4, 8] | Fatia de tempo de cada fila | +| Intervalo de boost | 20 ticks | A cada N ticks, todos os processos sobem para a fila 0 | + +--- + +## Modelos de Threads + +O PSS suporta simulação de **threads** dentro de processos, implementando os três modelos clássicos descritos em Sistemas Operacionais. + +### Conceitos Gerais + +- Um processo pode ter **N threads de usuário**, cada uma com sua própria sequência de bursts (CPU e I/O). +- A política de escalonamento entre threads de um mesmo processo é configurável: **FCFS**, **Round Robin** ou **Prioridade**. +- O modelo de thread determina como threads de usuário se mapeiam para threads de kernel. + +### MANY_TO_ONE (N:1) + +**N threads de usuário → 1 thread de kernel** + +- Apenas uma thread pode usar a CPU por vez dentro do processo. +- Se qualquer thread iniciar I/O, **todo o processo bloqueia** (a thread de kernel fica presa). +- Sem paralelismo real; muito simples de implementar. +- Simulado pelos presets `many_to_one`. + +### ONE_TO_ONE (1:1) + +**Cada thread de usuário → 1 thread de kernel dedicada** + +- Threads bloqueiam **independentemente**: se a Thread A faz I/O, as Threads B e C continuam na fila Ready. +- Processo só termina quando **todas** as threads terminam. +- Processo bloqueia somente quando todas as threads estão simultâneamente em I/O. +- Simulado pelos presets `one_to_one`. + +### MANY_TO_MANY (N:M) + +**N threads de usuário → M threads de kernel (M ≤ N)** + +- O número de threads de kernel (`kernelThreadCount`) é configurável. +- Se todas as M slots de kernel estiverem ocupadas, threads de usuário adicionais ficam em **fila de espera de kernel** (`KernelWait`). +- Combina flexibilidade com controle de recursos: mais threads ativas que N:1 mas menos overhead que 1:1. +- Simulado pelos presets `many_to_many`. + +### Política Intra-Processo + +Define como o escalonador seleciona a próxima thread quando há múltiplas threads Ready no mesmo processo: + +| Política | Comportamento | +|----------|--------------| +| **FCFS** | Thread mais antiga na fila Ready é selecionada | +| **Round Robin (RR)** | Cada thread recebe `threadQuantum` ticks; ao esgotar, vai para o fim da fila | +| **Priority** | Thread de maior prioridade é selecionada; preempção imediata se nova thread de maior prioridade chegar | + +### Diagrama de Gantt com Threads + +Quando um processo possui threads, o Gantt exibe **sub-linhas** abaixo da linha do processo, uma por thread, com cores derivadas da cor do processo (deslocamento de matiz de 40° por thread). O estado de cada thread (New, Ready, Running, Waiting, Terminated) é colorido com as mesmas variáveis CSS dos processos. + +--- + ## Referências - Silberschatz, A., Galvin, P. B., & Gagne, G., *Operating System Concepts*, 10ª edição. diff --git a/docs/metrics.en.md b/docs/metrics.en.md index 9f49e6a..344f239 100644 --- a/docs/metrics.en.md +++ b/docs/metrics.en.md @@ -105,6 +105,41 @@ The total height of each bar equals the **Turnaround Time** of the process. --- +## Thread Metrics + +When a process has threads, PSS computes individual metrics for each thread. These metrics are displayed in the **Threads** tab of the metrics panel (visible only when there are processes with threads). + +### Per-Thread Metrics + +| Metric | Formula | What it means | +|--------|---------|----------------| +| **Arrival Time** | `arrivalTick` | Tick at which the thread first entered the Ready queue | +| **Start** | `startTick` | Tick at which the thread first used the CPU | +| **Finish** | `finishTick` | Tick at which the thread completed all of its bursts | +| **Response Time** | `startTick − arrivalTick` | How long the thread waited before receiving the CPU for the first time | +| **Turnaround Time** | `finishTick − arrivalTick` | Total lifetime of the thread (arrival → completion) | +| **Waiting Time** | `turnaround − cpuTime − ioTime` | Time in the Ready queue without doing anything useful | +| **CPU Time** | Σ ticks in Running state | Total CPU consumed by the thread | +| **I/O Time** | Σ ticks in Waiting state | Total time waiting for I/O | + +### Thread Models and their impact on metrics + +The thread model directly affects the recorded times: + +| Model | Impact on Waiting Time | +|-------|------------------------| +| **MANY_TO_ONE** | Waiting Time tends to be high: any thread's I/O blocks the entire process, forcing other threads to wait | +| **ONE_TO_ONE** | Lower Waiting Time: threads block independently; while one does I/O, the others remain in the Ready queue | +| **MANY_TO_MANY** | Intermediate Waiting Time: threads that exceed the kernel slots enter `KernelWait` (shown with reduced opacity in the Gantt chart) | + +### Visualization + +The thread table displays inline horizontal mini progress bars in the Response, Turnaround, Waiting, CPU, and I/O columns, normalized by the largest value in each column across all threads — just like the process metrics table. + +Each thread has a color derived from the parent process color (40° HSL hue shift per thread), shown as a colored dot in the table and as a sub-row in the Gantt chart. + +--- + ## Example Consider three processes with the following bursts: diff --git a/docs/metrics.md b/docs/metrics.md index b664aae..30c493a 100644 --- a/docs/metrics.md +++ b/docs/metrics.md @@ -105,6 +105,41 @@ A altura total de cada barra equivale ao **Turnaround Time** do processo. --- +## Métricas de Threads + +Quando um processo possui threads, o PSS calcula métricas individuais para cada thread. Essas métricas são exibidas na aba **Threads** do painel de métricas (visível apenas quando há processos com threads). + +### Métricas por Thread + +| Métrica | Fórmula | O que significa | +|---------|---------|----------------| +| **Arrival Time** | `arrivalTick` | Tick em que a thread entrou pela primeira vez na fila Ready | +| **Start** | `startTick` | Tick em que a thread usou a CPU pela primeira vez | +| **Finish** | `finishTick` | Tick em que a thread encerrou todos os seus bursts | +| **Response Time** | `startTick − arrivalTick` | Quanto a thread esperou antes de receber a CPU pela primeira vez | +| **Turnaround Time** | `finishTick − arrivalTick` | Tempo total de vida da thread (chegada → término) | +| **Waiting Time** | `turnaround − cpuTime − ioTime` | Tempo na fila Ready sem executar nada útil | +| **CPU Time** | Σ ticks em estado Running | Total de CPU consumido pela thread | +| **I/O Time** | Σ ticks em estado Waiting | Total de tempo aguardando I/O | + +### Modelos de Thread e seu impacto nas métricas + +O modelo de thread afeta diretamente os tempos registrados: + +| Modelo | Impacto no Waiting Time | +|--------|------------------------| +| **MANY_TO_ONE** | Waiting Time tende a ser alto: qualquer I/O de uma thread bloqueia todo o processo, forçando as demais threads a esperarem | +| **ONE_TO_ONE** | Waiting Time menor: threads bloqueiam independentemente; enquanto uma faz I/O, as outras continuam na fila Ready | +| **MANY_TO_MANY** | Waiting Time intermediário: threads que excedem os slots de kernel ficam em `KernelWait` (indicadas com `opacity` reduzida no Gantt) | + +### Visualização + +A tabela de threads exibe mini barras de progresso horizontais nas colunas de Response, Turnaround, Waiting, CPU e I/O, normalizadas pelo maior valor de cada coluna entre todas as threads — assim como na tabela de processos. + +Cada thread possui uma cor derivada da cor do processo pai (deslocamento de matiz HSL de 40° por thread), exibida como ponto colorido na tabela e como sub-linha no Gantt. + +--- + ## Exemplo Considere três processos com os seguintes bursts: diff --git a/package-lock.json b/package-lock.json index ba8dc44..f60dcf9 100644 --- a/package-lock.json +++ b/package-lock.json @@ -147,6 +147,7 @@ "integrity": "sha512-CGOfOJqWjg2qW/Mb6zNsDm+u5vFQ8DxXfbM09z69p5Z6+mE1ikP2jUXw+j42Pf1XTYED2Rni5f95npYeuwMDQA==", "dev": true, "license": "MIT", + "peer": true, "dependencies": { "@babel/code-frame": "^7.29.0", "@babel/generator": "^7.29.0", @@ -519,6 +520,7 @@ } ], "license": "MIT", + "peer": true, "engines": { "node": ">=20.19.0" }, @@ -567,6 +569,7 @@ } ], "license": "MIT", + "peer": true, "engines": { "node": ">=20.19.0" } @@ -1892,8 +1895,7 @@ "resolved": "https://registry.npmjs.org/@types/aria-query/-/aria-query-5.0.4.tgz", "integrity": "sha512-rfT93uj5s0PRL7EzccGMs3brplhcrghnDoV26NqKhCAS1hVo+WdNsPvE/yb6ilfr5hi2MEk6d5EWJTKdxg8jVw==", "dev": true, - "license": "MIT", - "peer": true + "license": "MIT" }, "node_modules/@types/babel__core": { "version": "7.20.5", @@ -2034,6 +2036,7 @@ "integrity": "sha512-jp2P3tQMSxWugkCUKLRPVUpGaL5MVFwF8RDuSRztfwgN1wmqJeMSbKlnEtQqU8UrhTmzEmZdu2I6v2dpp7XIxw==", "dev": true, "license": "MIT", + "peer": true, "dependencies": { "undici-types": "~7.18.0" } @@ -2051,6 +2054,7 @@ "integrity": "sha512-z9VXpC7MWrhfWipitjNdgCauoMLRdIILQsAEV+ZesIzBq/oUlxk0m3ApZuMFCXdnS4U7KrI+l3WRUEGQ8K1QKw==", "devOptional": true, "license": "MIT", + "peer": true, "dependencies": { "@types/prop-types": "*", "csstype": "^3.2.2" @@ -2062,6 +2066,7 @@ "integrity": "sha512-MEe3UeoENYVFXzoXEWsvcpg6ZvlrFNlOQ7EOsvhI3CfAXwzPfO8Qwuxd40nepsYKqyyVQnTdEfv68q91yLcKrQ==", "dev": true, "license": "MIT", + "peer": true, "peerDependencies": { "@types/react": "^18.0.0" } @@ -2373,6 +2378,7 @@ } ], "license": "MIT", + "peer": true, "dependencies": { "baseline-browser-mapping": "^2.9.0", "caniuse-lite": "^1.0.30001759", @@ -2725,8 +2731,7 @@ "resolved": "https://registry.npmjs.org/dom-accessibility-api/-/dom-accessibility-api-0.5.16.tgz", "integrity": "sha512-X7BJ2yElsnOJ30pZF4uIIDfBEVgF4XEBxL9Bxhy6dnrm5hkzqmsWHGTiHqRiITNhMyFLyAiWndIJP7Z1NTteDg==", "dev": true, - "license": "MIT", - "peer": true + "license": "MIT" }, "node_modules/eastasianwidth": { "version": "0.2.0", @@ -3544,7 +3549,6 @@ "integrity": "sha512-h5bgJWpxJNswbU7qCrV0tIKQCaS3blPDrqKWx+QxzuzL1zGUzij9XCWLrSLsJPu5t+eWA/ycetzYAO5IOMcWAQ==", "dev": true, "license": "MIT", - "peer": true, "bin": { "lz-string": "bin/bin.js" } @@ -3760,6 +3764,7 @@ "integrity": "sha512-5gTmgEY/sqK6gFXLIsQNH19lWb4ebPDLA4SdLP7dsWkIXHWlG66oPuVvXSGFPppYZz8ZDZq0dYYrbHfBCVUb1Q==", "dev": true, "license": "MIT", + "peer": true, "engines": { "node": ">=12" }, @@ -3802,7 +3807,6 @@ "integrity": "sha512-Qb1gy5OrP5+zDf2Bvnzdl3jsTf1qXVMazbvCoKhtKqVs4/YK4ozX4gKQJJVyNe+cajNPn0KoC0MC3FUmaHWEmQ==", "dev": true, "license": "MIT", - "peer": true, "dependencies": { "ansi-regex": "^5.0.1", "ansi-styles": "^5.0.0", @@ -3818,7 +3822,6 @@ "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", "dev": true, "license": "MIT", - "peer": true, "engines": { "node": ">=8" } @@ -3829,7 +3832,6 @@ "integrity": "sha512-Cxwpt2SfTzTtXcfOlzGEee8O+c+MmUgGrNiBcXnuWxuFJHe6a5Hz7qwhwe5OgaSYI0IJvkLqWX1ASG+cJOkEiA==", "dev": true, "license": "MIT", - "peer": true, "engines": { "node": ">=10" }, @@ -3852,6 +3854,7 @@ "resolved": "https://registry.npmjs.org/react/-/react-18.3.1.tgz", "integrity": "sha512-wS+hAgJShR0KhEvPJArfuPVN1+Hz1t0Y6n5jLrGQbkb4urgPE/0Rve+1kMB1v/oWgHgm4WIcV+i7F2pTVj+2iQ==", "license": "MIT", + "peer": true, "dependencies": { "loose-envify": "^1.1.0" }, @@ -3864,6 +3867,7 @@ "resolved": "https://registry.npmjs.org/react-dom/-/react-dom-18.3.1.tgz", "integrity": "sha512-5m4nQKp+rZRb09LNH59GM4BxTh9251/ylbKIbpe7TpGxfJ+9kv6BLkLBXIjjspbgbnIBNqlI23tRnTWT0snUIw==", "license": "MIT", + "peer": true, "dependencies": { "loose-envify": "^1.1.0", "scheduler": "^0.23.2" @@ -3884,6 +3888,7 @@ "resolved": "https://registry.npmjs.org/react-redux/-/react-redux-9.2.0.tgz", "integrity": "sha512-ROY9fvHhwOD9ySfrF0wmvu//bKCQ6AeZZq1nJNtbDC+kk5DuSuNX/n6YWYF/SYy7bSba4D4FSz8DJeKY/S/r+g==", "license": "MIT", + "peer": true, "dependencies": { "@types/use-sync-external-store": "^0.0.6", "use-sync-external-store": "^1.4.0" @@ -3960,7 +3965,8 @@ "version": "5.0.1", "resolved": "https://registry.npmjs.org/redux/-/redux-5.0.1.tgz", "integrity": "sha512-M9/ELqF6fy8FwmkpnF0S3YKOqMyoWJ4+CS5Efg2ct3oY9daQvd/Pc71FpGZsVsbl3Cpb+IIcjBDUnnyBdQbq4w==", - "license": "MIT" + "license": "MIT", + "peer": true }, "node_modules/redux-thunk": { "version": "3.1.0", @@ -4546,6 +4552,7 @@ "integrity": "sha512-+Oxm7q9hDoLMyJOYfUYBuHQo+dkAloi33apOPP56pzj+vsdJDzr+j1NISE5pyaAuKL4A3UD34qd0lx5+kfKp2g==", "dev": true, "license": "MIT", + "peer": true, "dependencies": { "esbuild": "^0.25.0", "fdir": "^6.4.4", @@ -4644,6 +4651,7 @@ "integrity": "sha512-LUCP5ev3GURDysTWiP47wRRUpLKMOfPh+yKTx3kVIEiu5KOMeqzpnYNsKyOoVrULivR8tLcks4+lga33Whn90A==", "dev": true, "license": "MIT", + "peer": true, "dependencies": { "@types/chai": "^5.2.2", "@vitest/expect": "3.2.4", diff --git a/package.json b/package.json index 99bfb9f..98dd77b 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "pss", - "version": "1.2.0", + "version": "1.3.0", "description": "Process Scheduler Simulator — an interactive educational tool that runs entirely in the browser", "main": "index.js", "scripts": { diff --git a/src/components/ControlBar/ControlBar.tsx b/src/components/ControlBar/ControlBar.tsx index 95e5dea..a1fe062 100644 --- a/src/components/ControlBar/ControlBar.tsx +++ b/src/components/ControlBar/ControlBar.tsx @@ -66,7 +66,7 @@ const ControlBar = () => { return (