Questão de Sistemas Operacionais — Gerência de Memória (Paginação, Virtual, etc.) — INSTITUTO AOCP 2024

Alocação de memória dinâmica: blocos de tamanho fixo

Gabarito: letra C. Quando um sistema operacional usa alocação de memória em blocos de tamanho fixo (como no alocador Buddy, que trabalha com blocos de tamanho $2^n$) e um processo solicita 100 bytes, o algoritmo aloca o menor bloco de tamanho fixo que seja maior ou igual à solicitação — no caso, um bloco de 200 bytes, gerando fragmentação interna (os 100 bytes não utilizados dentro do bloco). As alternativas A, B, D e E estão incorretas por diferentes motivos, que veremos a seguir.

O problema central aqui é entender o que significa alocação de memória em blocos de tamanho fixo. Diferente da alocação contígua clássica (onde o processo recebe exatamente o tamanho que pediu, se houver um buraco livre suficiente), a alocação por blocos fixos divide a memória em partições de tamanho predeterminado — como páginas, no caso da paginação, ou blocos de tamanho $2^n$, no caso do alocador Buddy. O processo não recebe um tamanho arbitrário: ele recebe o menor bloco disponível que consiga contê-lo. Isso é uma consequência direta do mecanismo: como os blocos têm tamanho fixo, não é possível alocar "100 bytes exatos" se não existe um bloco de 100 bytes — o sistema precisa arredondar para cima.

Esse arredondamento gera o fenômeno da fragmentação interna: o espaço desperdiçado dentro do bloco alocado, que não pode ser usado por nenhum outro processo. No exemplo do enunciado, o processo pede 100 bytes, mas recebe um bloco de 200 bytes — os 100 bytes restantes ficam ociosos dentro do bloco, inutilizáveis. É exatamente isso que a alternativa C descreve: "alocar memória em um bloco de tamanho de 200 bytes e fragmentar a memória". A fragmentação aqui é interna, não externa — a externa ocorre quando há buracos livres entre blocos alocados, mas nenhum deles é grande o suficiente para atender a uma solicitação.

O alocador Buddy, mencionado no material de apoio, é o exemplo clássico desse tipo de alocação. Ele sempre aloca blocos de tamanho $2^n$ (1, 2, 4, 8, 16... KB), e para uma requisição de 85 KB, por exemplo, aloca um bloco de 128 KB — o menor bloco de tamanho $2^n$ que pode conter 85 KB. A lógica é idêntica à da questão: o processo pede 100 bytes, o menor bloco de tamanho fixo que o contém é o de 200 bytes (assumindo que os blocos disponíveis são de 100, 200, 400... ou de 128, 256... — o enunciado não especifica, mas a alternativa C assume 200). O desperdício de 100 bytes é a fragmentação interna, um custo inerente a esse tipo de alocação.

A pegadinha da banca está em confundir o leitor com alternativas que parecem plausíveis à primeira vista. A alternativa A sugere dividir a solicitação em dois blocos de 50 bytes — mas isso viola o princípio da alocação em blocos fixos, que não "quebra" uma solicitação em pedaços menores; ela é atendida por um único bloco. A alternativa B afirma que o sistema alocaria um bloco de 100 bytes, mas o enunciado diz explicitamente que não existem blocos de 100 bytes disponíveis — então isso é impossível. As alternativas D e E introduzem a ideia de "esperar" por liberação de memória, o que não é uma ação do algoritmo de alocação em blocos fixos: ele simplesmente aloca o próximo bloco maior disponível, sem esperar.

Guarde o critério decisivo: em alocação por blocos de tamanho fixo, o processo recebe o menor bloco que o contém, e o espaço excedente vira fragmentação interna. É exatamente essa lógica que separa a alternativa correta das demais.

Alternativa A — ❌ Incorreta

Alocar memória em dois blocos de 50 bytes cada. Isso não é possível em um sistema de blocos de tamanho fixo: a solicitação de 100 bytes deve ser atendida por um único bloco que a contenha, não pela soma de blocos menores. O algoritmo não fragmenta a solicitação em pedaços; ele arredonda o tamanho para cima até o próximo bloco disponível. Além disso, mesmo que fosse possível, isso criaria dois blocos alocados para um único processo, o que não é o comportamento descrito.

Alternativa B — ❌ Incorreta

Alocar memória em um bloco de tamanho de 100 bytes e fragmentar a memória. O enunciado afirma categoricamente que não existem blocos de 100 bytes disponíveis. Portanto, o algoritmo não pode alocar um bloco desse tamanho. A alternativa ignora a premissa central da questão. Se houvesse um bloco de 100 bytes, ele seria alocado sem fragmentação — mas não há.

Alternativa C — ✅ Correta ⟵ GABARITO

Alocar memória em um bloco de tamanho de 200 bytes e fragmentar a memória. Esta é a resposta correta. Como não há blocos de 100 bytes, o algoritmo aloca o menor bloco de tamanho fixo disponível que seja maior que 100 bytes — no caso, 200 bytes. O espaço excedente (100 bytes) fica ocioso dentro do bloco, caracterizando fragmentação interna. Esse é o comportamento típico de alocadores como o Buddy, que sempre arredondam a solicitação para o próximo tamanho de bloco disponível.

Alternativa D — ❌ Incorreta

Alocar memória em um bloco de tamanho de 100 bytes e esperar que um processo finalize para liberar a memória. Dois erros: primeiro, não há blocos de 100 bytes disponíveis (premissa do enunciado). Segundo, o algoritmo de alocação em blocos fixos não espera por liberação de memória — ele simplesmente aloca o próximo bloco maior disponível. A espera por liberação é um comportamento de outros contextos (como quando não há memória suficiente), não deste.

Alternativa E — ❌ Incorreta

Alocar memória em um bloco de tamanho de 200 bytes e esperar que o processo finalize. A primeira parte está correta (alocar 200 bytes), mas a segunda não: o algoritmo não "espera o processo finalizar" como parte do processo de alocação. A alocação é imediata — o bloco de 200 bytes é alocado e o processo começa a executar. A espera por finalização seria relevante apenas para a liberação da memória, não para a alocação. A alternativa mistura o momento da alocação com o da liberação.

Gabarito: letra C