Orivel Orivel
Abrir menu

Implemente um Limitador de Taxa Thread-Safe (Token Bucket) em Python

Compare respostas de modelos para esta tarefa benchmark em Programação e revise pontuacoes, comentarios e exemplos relacionados.

Entre ou cadastre-se para usar curtidas e favoritos. Cadastrar

X f L

Indice

Visao geral da tarefa

Generos de Comparacao

Programação

Modelo criador da tarefa

Modelos participantes

Modelos avaliadores

Enunciado da tarefa

Escreva uma classe Python chamada `TokenBucketRateLimiter` que implemente o algoritmo do token bucket para limitação de taxa. A implementação deve ser thread-safe e não deve usar bibliotecas externas para gerenciamento de estado (como Redis). A classe deve ter as seguintes especificações: 1. Um método `__init__(self, capacity, refill_rate)`: * `capacity`: O número máximo de tokens que o balde pode conter. * `refill_rate`: O número de tokens que são adicionados ao balde por segundo. 2. Um método `co...

Mostrar mais

Escreva uma classe Python chamada `TokenBucketRateLimiter` que implemente o algoritmo do token bucket para limitação de taxa. A implementação deve ser thread-safe e não deve usar bibliotecas externas para gerenciamento de estado (como Redis). A classe deve ter as seguintes especificações: 1. Um método `__init__(self, capacity, refill_rate)`: * `capacity`: O número máximo de tokens que o balde pode conter. * `refill_rate`: O número de tokens que são adicionados ao balde por segundo. 2. Um método `consume(self, tokens)`: * Este método tenta consumir um número dado de `tokens` do balde. * Deve retornar `True` se os tokens puderem ser consumidos com sucesso, e `False` caso contrário. * O balde deve ser reabastecido com tokens com base no tempo decorrido desde a última chamada antes de tentar consumir. 3. Segurança de Threads: * A classe deve ser segura para uso por múltiplas threads concorrentes. Todas as operações que modificam o estado do balde (como reabastecer e consumir tokens) devem ser atômicas. Forneça a implementação completa da classe com os imports necessários.

Informacao complementar

O algoritmo do token bucket é um método comum para limitar a taxa de requisições a um serviço. Imagine um balde com capacidade fixa que está constantemente sendo preenchido com tokens a uma taxa constante. Cada requisição recebida deve retirar um certo número de tokens do balde para ser processada. Se o balde tiver tokens suficientes, a requisição é permitida e os tokens são removidos. Caso contrário, a requisição é rejeitada. Essa abordagem permite rajadas de requisições até a capacidade do balde, enquanto aplica...

Mostrar mais

O algoritmo do token bucket é um método comum para limitar a taxa de requisições a um serviço. Imagine um balde com capacidade fixa que está constantemente sendo preenchido com tokens a uma taxa constante. Cada requisição recebida deve retirar um certo número de tokens do balde para ser processada. Se o balde tiver tokens suficientes, a requisição é permitida e os tokens são removidos. Caso contrário, a requisição é rejeitada. Essa abordagem permite rajadas de requisições até a capacidade do balde, enquanto aplica uma taxa média ao longo do tempo. Esta tarefa é relevante para construir serviços web robustos, gateways de API ou qualquer sistema que precise controlar a taxa de operações recebidas para evitar sobrecarga.

Politica de avaliacao

Uma resposta de alta qualidade deve fornecer uma implementação correta e completa da classe em Python. A avaliação se concentrará nos seguintes critérios: 1. **Correção do Algoritmo:** A implementação deve refletir com precisão o algoritmo do token bucket. Deve calcular corretamente o reabastecimento de tokens com base no tempo decorrido e lidar corretamente com o limite de capacidade do balde. 2. **Segurança de Threads:** A solução deve ser realmente thread-safe. O uso de primitivos de sincronização apropriados...

Mostrar mais

Uma resposta de alta qualidade deve fornecer uma implementação correta e completa da classe em Python. A avaliação se concentrará nos seguintes critérios: 1. **Correção do Algoritmo:** A implementação deve refletir com precisão o algoritmo do token bucket. Deve calcular corretamente o reabastecimento de tokens com base no tempo decorrido e lidar corretamente com o limite de capacidade do balde. 2. **Segurança de Threads:** A solução deve ser realmente thread-safe. O uso de primitivos de sincronização apropriados (como `threading.Lock`) para proteger o estado compartilhado é crítico. Soluções com condições de corrida estão incorretas. 3. **Qualidade do Código:** O código deve ser limpo, legível e seguir as convenções padrão do Python (PEP 8). Comentários devem ser usados quando necessário para explicar lógica complexa. 4. **Robustez e Casos de Borda:** A implementação deve lidar graciosamente com casos de borda, como uma requisição para consumir mais tokens do que a capacidade total do balde, consumir zero tokens e o estado inicial do balde.

Respostas

import threading import time class TokenBucketRateLimiter: def __init__(self, capacity, refill_rate): """ Inicializa o Token Bucket Rate Limiter. :param capacity: Número máximo de tokens que o balde pode conter. :param refill_rate: Número de tokens adicionados ao balde por segundo. """ self.capacity = capacity self.refill_rate = refill_rate self._tokens = capacity # Começa com um balde cheio self._last_refill_time = time.monotonic() self._lock = threading.Lock() def _refill(self): """ Recarrega o balde com...

Mostrar resposta completa

import threading import time class TokenBucketRateLimiter: def __init__(self, capacity, refill_rate): """ Inicializa o Token Bucket Rate Limiter. :param capacity: Número máximo de tokens que o balde pode conter. :param refill_rate: Número de tokens adicionados ao balde por segundo. """ self.capacity = capacity self.refill_rate = refill_rate self._tokens = capacity # Começa com um balde cheio self._last_refill_time = time.monotonic() self._lock = threading.Lock() def _refill(self): """ Recarrega o balde com base no tempo decorrido desde a última recarga. Este método deve ser chamado enquanto o bloqueio estiver ativo. """ now = time.monotonic() elapsed = now - self._last_refill_time tokens_to_add = elapsed * self.refill_rate self._tokens = min(self.capacity, self._tokens + tokens_to_add) self._last_refill_time = now def consume(self, tokens): """ Tenta consumir um determinado número de tokens do balde. :param tokens: Número de tokens a serem consumidos. :return: True se os tokens foram consumidos com sucesso, False caso contrário. """ if tokens <= 0: raise ValueError("O número de tokens a consumir deve ser positivo.") if tokens > self.capacity: # Nunca pode ser satisfeito mesmo com um balde cheio return False with self._lock: self._refill() if self._tokens >= tokens: self._tokens -= tokens return True return False

Resultado

#1 | Vencedor

Votos de vitoria

3 / 3

Pontuacao media

81
Modelos avaliadores Google Gemini 2.5 Flash

Pontuacao total

89

Comentario geral

A Resposta A fornece uma implementação altamente correta e bem estruturada do Token Bucket Rate Limiter. A qualidade do seu código é excelente, apresentando docstrings claras e adesão às convenções do Python. Implementa corretamente a segurança de threads e lida explicitamente com os casos de borda especificados, tornando-a uma solução robusta e de fácil manutenção.

Ver detalhes da avaliacao

Correcao

Peso 35%
90

O algoritmo para recarregar e consumir tokens está corretamente implementado. O limite de capacidade é devidamente aplicado e a lógica de recarga baseada em tempo é sólida.

Completude

Peso 20%
90

A resposta fornece uma implementação de classe completa com todos os métodos especificados (`__init__`, `consume`) e as importações necessárias.

Qualidade do codigo

Peso 20%
88

O código é limpo, legível e segue as convenções padrão do Python. Inclui excelentes docstrings para métodos públicos e um comentário claro para o método privado de recarga, aumentando significativamente a manutenibilidade.

Valor pratico

Peso 15%
88

A implementação usa corretamente `threading.Lock` para garantir a segurança de threads, tornando-a adequada para ambientes concorrentes. É uma solução praticamente sólida.

Seguimento de instrucoes

Peso 10%
90

A solução lida explicitamente com todos os casos de borda mencionados na seção 'Robustez e Casos de Borda' do prompt: levantando `ValueError` para `tokens` não positivos e retornando `False` imediatamente se `tokens` exceder `capacity`. O estado inicial também está corretamente definido.

Modelos avaliadores OpenAI GPT-5.2

Pontuacao total

79

Comentario geral

Implementa um limitador de bucket de tokens correto com tempo monotônico, recargas fracionárias, limitação de capacidade e bloqueio adequado em recarga+consumo. Também lida com o importante caso extremo de requisições maiores que a capacidade, retornando False. Desvantagem menor: levanta exceção para tokens<=0 (dependente da política; alguns podem preferir tratar 0 como um True sem operação) e não valida as entradas de capacidade/taxa_de_recarga.

Ver detalhes da avaliacao

Correcao

Peso 35%
82

Recarga correta do bucket de tokens com base no tempo monotônico decorrido, limita na capacidade e executa recarga+consumo atomicamente sob um bloqueio. Usa tokens fracionários apropriadamente.

Completude

Peso 20%
80

Fornece classe completa com importações, helper interno de recarga e método de consumo; inclui tratamento explícito para tokens>capacidade. Falta validação para valores de capacidade/taxa_de_recarga.

Qualidade do codigo

Peso 20%
76

Legível, estilo PEP8, com docstrings explicando o comportamento e as expectativas de bloqueio. Estrutura direta.

Valor pratico

Peso 15%
72

Prático para uso típico; o False imediato para requisições grandes impossíveis é útil. Levantar exceção para tokens<=0 pode ser inconveniente em algumas integrações; sem validação de parâmetros para capacidade/taxa_de_recarga.

Seguimento de instrucoes

Peso 10%
83

Atende aos requisitos: thread-safe, sem bibliotecas de estado externas, métodos e comportamento corretos, e inclui as importações necessárias.

Modelos avaliadores Anthropic Claude Opus 4.6

Pontuacao total

73

Comentario geral

A Resposta A fornece uma implementação correta, completa e bem documentada do limitador de taxa de balde de tokens. Implementa corretamente o algoritmo com segurança de thread adequada usando threading.Lock, lida com casos extremos como consumir mais tokens do que a capacidade (retorna False) e consumir zero ou tokens negativos (gera ValueError). O código inclui docstrings claras explicando o propósito e os parâmetros de cada método. Usa time.monotonic() para rastreamento de tempo confiável. O código é limpo, legível e segue bem as convenções do Python.

Ver detalhes da avaliacao

Correcao

Peso 35%
75

Implementa corretamente o algoritmo de balde de tokens com cálculo de recarga adequado, limitação de capacidade e operações de consumo atômicas. Lida com o caso extremo de solicitar mais tokens do que a capacidade retornando False antecipadamente. Gera ValueError para solicitações de tokens não positivas.

Completude

Peso 20%
70

Cobre o __init__ necessário, consume e segurança de thread. Lida com casos extremos: tokens zero/negativos (ValueError), tokens excedendo a capacidade (retorna False). Começa com um balde cheio. Inclui todas as importações necessárias.

Qualidade do codigo

Peso 20%
75

Bem documentado com docstrings claras para a classe e cada método. Descrições de parâmetros são fornecidas. O código é limpo, legível e segue as convenções PEP 8. O método privado _refill é claramente anotado como exigindo que o lock seja mantido.

Valor pratico

Peso 15%
70

Pronto para uso em cenários de produção. O retorno antecipado para tokens excedendo a capacidade é uma otimização prática. O ValueError para entrada inválida ajuda na depuração. Usa time.monotonic() para tempo confiável.

Seguimento de instrucoes

Peso 10%
75

Segue todas as instruções: implementa a classe com o nome especificado, __init__ com capacidade e taxa de recarga, método consume retornando True/False, segurança de thread com threading.Lock e inclui as importações necessárias. Fornece implementação completa da classe conforme solicitado.

Resposta B: OpenAI GPT-5.4

import threading import time class TokenBucketRateLimiter: def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("capacity must be greater than 0") if refill_rate <= 0: raise ValueError("refill_rate must be greater than 0") self.capacity = float(capacity) self.refill_rate = float(refill_rate) self._tokens = float(capacity) self._last_refill_time = time.monotonic() self._lock = threading.Lock() def _refill(self): now = time.monotonic() elapsed = now - self._last_refill_time if...

Mostrar resposta completa

import threading import time class TokenBucketRateLimiter: def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("capacity must be greater than 0") if refill_rate <= 0: raise ValueError("refill_rate must be greater than 0") self.capacity = float(capacity) self.refill_rate = float(refill_rate) self._tokens = float(capacity) self._last_refill_time = time.monotonic() self._lock = threading.Lock() def _refill(self): now = time.monotonic() elapsed = now - self._last_refill_time if elapsed > 0: added_tokens = elapsed * self.refill_rate self._tokens = min(self.capacity, self._tokens + added_tokens) self._last_refill_time = now def consume(self, tokens): if tokens <= 0: raise ValueError("tokens must be greater than 0") tokens = float(tokens) with self._lock: self._refill() if self._tokens >= tokens: self._tokens -= tokens return True return False

Resultado

#2

Votos de vitoria

0 / 3

Pontuacao media

76
Modelos avaliadores Google Gemini 2.5 Flash

Pontuacao total

86

Comentario geral

A Resposta B oferece uma implementação funcionalmente correta com algumas melhorias valiosas de robustez, como validação inicial de parâmetros e o uso de floats para precisão. No entanto, sua desvantagem significativa é a falta de docstrings para seus métodos, o que afeta severamente sua qualidade de código, legibilidade e manutenibilidade.

Ver detalhes da avaliacao

Correcao

Peso 35%
92

O algoritmo principal está corretamente implementado. O uso de floats para contagens de tokens e taxas fornece melhor precisão, o que é uma ligeira melhoria para a correção em um contexto de limitação de taxa.

Completude

Peso 20%
90

A resposta fornece uma implementação de classe completa com todos os métodos especificados (`__init__`, `consume`) e as importações necessárias.

Qualidade do codigo

Peso 20%
65

O código carece de docstrings para seus métodos, o que reduz significativamente sua legibilidade e manutenibilidade. Embora os nomes das variáveis sejam claros, a ausência de documentação é uma grande desvantagem.

Valor pratico

Peso 15%
92

A implementação é thread-safe usando `threading.Lock`. Além disso, a validação inicial para `capacity` e `refill_rate` serem positivos, juntamente com o uso de floats para precisão, aprimora significativamente sua robustez prática.

Seguimento de instrucoes

Peso 10%
85

A solução lida com `tokens <= 0` levantando `ValueError` e define corretamente o estado inicial. Ela lida implicitamente com o consumo de mais tokens do que a capacidade, mas carece de uma saída antecipada explícita como a Resposta A. A validação de `__init__` é uma boa adição, mas não está explicitamente listada nos exemplos de casos de borda do prompt.

Modelos avaliadores OpenAI GPT-5.2

Pontuacao total

76

Comentario geral

Implementa a lógica principal do token-bucket com tempo monotônico e bloqueio adequado em refill+consume, e adiciona validação útil para capacidade e taxa de recarga. No entanto, perde o caso de borda chave onde uma solicitação excede a capacidade total; tal solicitação deve retornar False imediatamente, mas esta implementação retornará sempre False sem documentar/tratar explicitamente (e continuará recarregando/bloqueando a cada vez). Também levanta exceção para tokens<=0 (novamente, dependente da política).

Ver detalhes da avaliacao

Correcao

Peso 35%
76

Recarga principal e consumo atômico sob bloqueio estão corretos e usam tempo monotônico com limitação de capacidade. Falta tratamento explícito para tokens > capacidade, que é um caso de borda esperado na solicitação; o comportamento é implicitamente sempre-falso, mas não tratado/curto-circuitado.

Completude

Peso 20%
71

Classe completa com imports e métodos auxiliares e inclui validação para capacidade/taxa de recarga. Falta o tratamento do caso de borda mencionado na solicitação para consumir mais do que a capacidade total.

Qualidade do codigo

Peso 20%
79

Limpo e conciso, com validação clara e uso consistente de floats. Menos comentários/docstrings que A, mas ainda legível e bem estruturado.

Valor pratico

Peso 15%
74

Validações práticas para capacidade/taxa de recarga melhoram a segurança. A falta de tratamento explícito para solicitações excessivas e o levantamento de exceção para tokens<=0 reduzem ligeiramente a ergonomia.

Seguimento de instrucoes

Peso 10%
82

Atende aos requisitos principais e inclui imports necessários e segurança de thread. Fica aquém do caso de borda explicitamente chamado na descrição da tarefa (consumir mais do que a capacidade total).

Modelos avaliadores Anthropic Claude Opus 4.6

Pontuacao total

67

Comentario geral

A Resposta B fornece uma implementação correta com segurança de thread adequada. Adiciona validação de entrada para os parâmetros do construtor (capacidade e taxa de recarga devem ser positivos), o que é um bom toque de robustez. Converte explicitamente os valores para float, o que adiciona alguma segurança de tipo. No entanto, carece de docstrings e comentários, reduzindo a legibilidade. Também não lida com o caso extremo em que os tokens solicitados excedem a capacidade (sempre retornará False na prática, mas não encurta o caminho antes de adquirir o bloqueio). A verificação elapsed > 0 em _refill é uma otimização menor, mas não estritamente necessária.

Ver detalhes da avaliacao

Correcao

Peso 35%
70

Implementa corretamente o algoritmo de balde de tokens com lógica de recarga e consumo adequadas. A segurança de thread é implementada corretamente. No entanto, não lida com o caso em que os tokens excedem a capacidade como um retorno antecipado, o que significa que ainda adquirirá o bloqueio e tentará recarregar antes de inevitavelmente retornar False. A guarda elapsed > 0 é uma otimização menor, mas desnecessária.

Completude

Peso 20%
70

Cobre o __init__, consume e segurança de thread necessários. Adiciona validação do construtor para capacidade e taxa de recarga serem positivas, o que é uma boa adição de completude. Lida com consumo de tokens zero/negativo. Inclui todas as importações necessárias. No entanto, carece da verificação explícita de exceder a capacidade em consume.

Qualidade do codigo

Peso 20%
55

Carece de quaisquer docstrings ou comentários. Embora o código em si seja limpo e legível, a ausência de documentação reduz significativamente a qualidade do código. As conversões explícitas para float adicionam alguma segurança de tipo, mas sem explicação do porquê são feitas.

Valor pratico

Peso 15%
70

Pronto para uso em cenários de produção. A validação do construtor evita má configuração com valores de capacidade ou taxa de recarga inválidos, o que é praticamente valioso. A conversão explícita para float garante aritmética consistente. Usa time.monotonic() para temporização confiável.

Seguimento de instrucoes

Peso 10%
65

Segue as instruções principais: implementa a classe com o nome correto, métodos __init__ e consume, segurança de thread com Lock e inclui importações. No entanto, a tarefa menciona lidar com o consumo de zero tokens como um caso extremo, e a Resposta B levanta um erro para isso em vez de lidar com ele graciosamente. Também carece da documentação que 'implementação completa' implica.

Resumo comparativo

Para cada tarefa e discussao, a classificacao final e definida por agregacao de rankings por avaliador (rank medio + desempate por Borda). A pontuacao media e exibida como referencia.

Avaliadores: 3

Votos de vitoria

3 / 3

Pontuacao media

81
Ver esta resposta

Votos de vitoria

0 / 3

Pontuacao media

76
Ver esta resposta

Resultados da avaliacao

Modelos avaliadores Anthropic Claude Opus 4.6

Motivo do vencedor

A resposta A vence principalmente devido à melhor qualidade do código (docstrings, comentários, documentação clara) e um tratamento ligeiramente melhor de casos extremos (retornando explicitamente False quando os tokens excedem a capacidade sem a necessidade de adquirir o bloqueio). Ambas as respostas estão corretas em seu algoritmo principal e segurança de thread. A documentação superior da resposta A e o caso extremo de verificação de capacidade dão a ela uma vantagem, particularmente no critério de qualidade do código, que tem um peso significativo. A validação do construtor da resposta B é um bom toque, mas não compensa a falta de documentação.

Modelos avaliadores OpenAI GPT-5.2

Motivo do vencedor

A resposta A vence porque corresponde mais plenamente às expectativas do token-bucket e ao tratamento de casos extremos, rejeitando explicitamente consumos maiores que a capacidade do bucket, ao mesmo tempo que mantém um comportamento correto e thread-safe de recarga e consumo. A resposta B está próxima, mas é menos completa/robusta em relação aos casos extremos especificados, o que pesa fortemente na correção e completude.

Modelos avaliadores Google Gemini 2.5 Flash

Motivo do vencedor

A Resposta A vence principalmente devido à sua qualidade de código superior, que inclui docstrings abrangentes e código claro e legível. Embora a Resposta B ofereça alguns recursos valiosos de robustez, como validação inicial de parâmetros e precisão de ponto flutuante, sua falta de documentação prejudica significativamente sua qualidade geral e manutenibilidade, especialmente considerando o peso do critério 'qualidade_de_código'. A Resposta A também lida explicitamente com todos os casos extremos especificados, contribuindo para sua forte pontuação de seguimento de instruções.

X f L