Многопоточность и синхронизация — бесплатный тест онлайн

Вопрос 1 из 30

Раздел «Потоки выполнения»: что здесь является частью контракта, а не особенностью одного удачного запуска?

Imports System.Threading
Module Demo
    Sub StartWorker()
        Dim thread = New Thread(Sub() Console.WriteLine("work"))
        thread.IsBackground = True
        thread.Start()
        thread.Join()
    End Sub
End Module

Разбор фрагмента: thread даёт низкоуровневый поток ОС и требует автоматическиго управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Разбор фрагмента: thread даёт низкоуровневый поток ОС и не требует явного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Разбор фрагмента: thread даёт низкоуровневый поток ОС и требует неявного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Разбор фрагмента: thread даёт низкоуровневый поток ОС и требует явного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Разбор фрагмента: достаточно обеспечить «для большинства задач предпочтительнее Task и пул потоков»; условие «Thread даёт низкоуровневый поток ОС и требует явного управления жизненным циклом» можно отдельно не проверять.

Вопрос 2 из 30

Раздел «Потоки выполнения»: что должно остаться явным после переработки участка с StartWorker?

Option Strict On
Imports System.Threading
Namespace ReviewCase21_1
    Module Demo
        Sub StartWorker()
            Dim reviewThread = New Thread(Sub() Console.WriteLine("work"))
            reviewThread.IsBackground = True
            reviewThread.Start()
            reviewThread.Join()
        End Sub
    End Module
End Namespace

Проверить перед объединением: thread даёт низкоуровневый поток ОС и требует неявного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Проверить перед объединением: thread даёт низкоуровневый поток ОС и требует явного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Проверить перед объединением: thread даёт низкоуровневый поток ОС и требует автоматическиго управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Проверить перед объединением: thread даёт низкоуровневый поток ОС и не требует явного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Проверить перед объединением: достаточно обеспечить «для большинства задач предпочтительнее Task и пул потоков»; условие «Thread даёт низкоуровневый поток ОС и требует явного управления жизненным циклом» можно отдельно не проверять.

Вопрос 3 из 30

Раздел «Потоки выполнения»: что именно должен локализовать полезный граничный тест для этого кода?

Option Explicit On
Option Infer On
Imports System.Threading
Namespace BoundaryCase21_1
    Module Demo
        Sub StartWorker()
            Dim edgeThread = New Thread(Sub() Console.WriteLine("work"))
            edgeThread.IsBackground = True
            edgeThread.Start()
            edgeThread.Join()
        End Sub
    End Module
End Namespace

Проверить на границе: thread даёт низкоуровневый поток ОС и требует неявного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Проверить на границе: thread даёт низкоуровневый поток ОС и требует явного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Проверить на границе: thread даёт низкоуровневый поток ОС и не требует явного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Проверить на границе: thread даёт низкоуровневый поток ОС и требует автоматическиго управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Проверить на границе: достаточно обеспечить «для большинства задач предпочтительнее Task и пул потоков»; условие «Thread даёт низкоуровневый поток ОС и требует явного управления жизненным циклом» можно отдельно не проверять.

Вопрос 4 из 30

Раздел «Потоки выполнения»: как уменьшить риск дефекта, не подменяя причину запасным значением?

Закрепить рабочее решение: thread даёт низкоуровневый поток ОС и не требует явного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Закрепить рабочее решение: достаточно обеспечить «для большинства задач предпочтительнее Task и пул потоков»; условие «Thread даёт низкоуровневый поток ОС и требует явного управления жизненным циклом» можно отдельно не проверять. Закрепить рабочее решение: thread даёт низкоуровневый поток ОС и требует явного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Закрепить рабочее решение: thread даёт низкоуровневый поток ОС и требует неявного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Закрепить рабочее решение: thread даёт низкоуровневый поток ОС и требует автоматическиго управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков.

Вопрос 5 из 30

Раздел «Потоки выполнения»: какое обобщение не зависит от случайных деталей показанного примера?

Рабочее правило: thread даёт низкоуровневый поток ОС и требует явного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Рабочее правило: thread даёт низкоуровневый поток ОС и требует автоматическиго управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Рабочее правило: thread даёт низкоуровневый поток ОС и не требует явного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Рабочее правило: thread даёт низкоуровневый поток ОС и требует неявного управления жизненным циклом; для большинства задач предпочтительнее Task и пул потоков. Рабочее правило: достаточно обеспечить «для большинства задач предпочтительнее Task и пул потоков»; условие «Thread даёт низкоуровневый поток ОС и требует явного управления жизненным циклом» можно отдельно не проверять.

Вопрос 6 из 30

Какой вывод о фрагменте по теме «Задачи Task» технически обоснован?

Imports System.Threading.Tasks
Module Demo
    Async Function CalculateAsync() As Task(Of Integer)
        Return Await Task.Run(Function() Enumerable.Range(1, 100000).Sum())
    End Function
End Module

Разбор фрагмента: для Задачи Task утверждение «а не гарантированный новый поток» определяет результат, а требование «Task представляет завершение работы» влияет только на читаемость. Разбор фрагмента: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и аасинхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Разбор фрагмента: контракт Задачи Task можно сократить до «Task представляет завершение работы»; часть «а не гарантированный новый поток» остаётся лишь рекомендацией. Разбор фрагмента: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и асинхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Разбор фрагмента: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и синхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма.

Вопрос 7 из 30

Раздел «Задачи Task»: что следует зафиксировать в ревью, чтобы ошибка не переехала из сборки в выполнение?

Option Strict On
Imports System.Threading.Tasks
Namespace ReviewCase21_2
    Module Demo
        Async Function CalculateAsync() As Task(Of Integer)
            Return Await Task.Run(Function() Enumerable.Range(1, 100000).Sum())
        End Function
    End Module
End Namespace

Зафиксировать в ревью: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и синхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Зафиксировать в ревью: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и асинхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Зафиксировать в ревью: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и аасинхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Зафиксировать в ревью: контракт Задачи Task можно сократить до «Task представляет завершение работы»; часть «а не гарантированный новый поток» остаётся лишь рекомендацией. Зафиксировать в ревью: для Задачи Task утверждение «а не гарантированный новый поток» определяет результат, а требование «Task представляет завершение работы» влияет только на читаемость.

Вопрос 8 из 30

Раздел «Задачи Task»: что именно должен локализовать полезный граничный тест для этого кода?

Option Explicit On
Option Infer On
Imports System.Threading.Tasks
Namespace BoundaryCase21_2
    Module Demo
        Async Function CalculateAsync() As Task(Of Integer)
            Return Await Task.Run(Function() Enumerable.Range(1, 100000).Sum())
        End Function
    End Module
End Namespace

Закрепить тестом: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и аасинхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Закрепить тестом: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и синхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Закрепить тестом: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и асинхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Закрепить тестом: контракт Задачи Task можно сократить до «Task представляет завершение работы»; часть «а не гарантированный новый поток» остаётся лишь рекомендацией. Закрепить тестом: для Задачи Task утверждение «а не гарантированный новый поток» определяет результат, а требование «Task представляет завершение работы» влияет только на читаемость.

Вопрос 9 из 30

Раздел «Задачи Task»: обычный сценарий в рабочем модуле проходит, но поведение ещё не закреплено проверкой. Какое решение не маскирует причину?

Оставить в коде и тестах условие: контракт Задачи Task можно сократить до «Task представляет завершение работы»; часть «а не гарантированный новый поток» остаётся лишь рекомендацией. Оставить в коде и тестах условие: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и синхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Оставить в коде и тестах условие: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и аасинхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Оставить в коде и тестах условие: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и асинхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Оставить в коде и тестах условие: для Задачи Task утверждение «а не гарантированный новый поток» определяет результат, а требование «Task представляет завершение работы» влияет только на читаемость.

Вопрос 10 из 30

Какое утверждение точнее отделяет «Задачи Task» от соседних механизмов?

Переносимый вывод: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и асинхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Переносимый вывод: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и синхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма. Переносимый вывод: контракт Задачи Task можно сократить до «Task представляет завершение работы»; часть «а не гарантированный новый поток» остаётся лишь рекомендацией. Переносимый вывод: для Задачи Task утверждение «а не гарантированный новый поток» определяет результат, а требование «Task представляет завершение работы» влияет только на читаемость. Переносимый вывод: task представляет завершение работы, а не гарантированный новый поток; CPU-задачи и аасинхронный ввод-вывод требуют разных способов запуска и ограничения параллелизма.

Вопрос 11 из 30

Какой контракт действительно соблюдает показанный фрагмент из раздела «Синхронизация через SyncLock»?

Class Counter
    Private ReadOnly gate As New Object()
    Private value As Integer
    Public Sub Increment()
        SyncLock gate
            value += 1
        End SyncLock
    End Sub
End Class

SyncLock защищает общий инвариант коротким критическим участком; блокироваться не нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. SyncLock защищает общий инвариант коротким критическим участком; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. SyncLock не защищает общий инвариант коротким критическим участком; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. SyncLock защищает общий инвариант коротким критическим участком; блокироваться нужно на публичном стабильном объекте и не выполнять внутри долгий ввод-вывод. SyncLock защищает общий инвариант всем методом вместе с вводом-выводом; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод.

Вопрос 12 из 30

Раздел «Синхронизация через SyncLock»: какая претензия к возможной правке относится к поведению программы?

Option Strict On
Namespace ReviewCase21_3
    Class Counter
        Private ReadOnly gate As New Object()
        Private value As Integer
        Public Sub Increment()
            SyncLock gate
                value += 1
            End SyncLock
        End Sub
    End Class
End Namespace

Зафиксировать в ревью: syncLock защищает общий инвариант коротким критическим участком; блокироваться нужно на публичном стабильном объекте и не выполнять внутри долгий ввод-вывод. Зафиксировать в ревью: syncLock защищает общий инвариант коротким критическим участком; блокироваться не нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Зафиксировать в ревью: syncLock защищает общий инвариант коротким критическим участком; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Зафиксировать в ревью: syncLock защищает общий инвариант всем методом вместе с вводом-выводом; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Зафиксировать в ревью: syncLock не защищает общий инвариант коротким критическим участком; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод.

Вопрос 13 из 30

Раздел «Синхронизация через SyncLock»: какое утверждение поможет отличить настоящий дефект от случайности тестовых данных?

Option Explicit On
Option Infer On
Namespace BoundaryCase21_3
    Class Counter
        Private ReadOnly gate As New Object()
        Private value As Integer
        Public Sub Increment()
            SyncLock gate
                value += 1
            End SyncLock
        End Sub
    End Class
End Namespace

Добавить регрессионную проверку: syncLock не защищает общий инвариант коротким критическим участком; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Добавить регрессионную проверку: syncLock защищает общий инвариант коротким критическим участком; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Добавить регрессионную проверку: syncLock защищает общий инвариант всем методом вместе с вводом-выводом; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Добавить регрессионную проверку: syncLock защищает общий инвариант коротким критическим участком; блокироваться не нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Добавить регрессионную проверку: syncLock защищает общий инвариант коротким критическим участком; блокироваться нужно на публичном стабильном объекте и не выполнять внутри долгий ввод-вывод.

Вопрос 14 из 30

Раздел «Синхронизация через SyncLock»: какой выбор не превращает скрытую ошибку в тихое продолжение работы?

Не скрывать за запасным сценарием: syncLock не защищает общий инвариант коротким критическим участком; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Не скрывать за запасным сценарием: syncLock защищает общий инвариант всем методом вместе с вводом-выводом; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Не скрывать за запасным сценарием: syncLock защищает общий инвариант коротким критическим участком; блокироваться не нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Не скрывать за запасным сценарием: syncLock защищает общий инвариант коротким критическим участком; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Не скрывать за запасным сценарием: syncLock защищает общий инвариант коротким критическим участком; блокироваться нужно на публичном стабильном объекте и не выполнять внутри долгий ввод-вывод.

Вопрос 15 из 30

Какое утверждение о «Синхронизация через SyncLock» выдерживает изменение имён и входных данных?

Рабочее правило: syncLock защищает общий инвариант коротким критическим участком; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Рабочее правило: syncLock защищает общий инвариант коротким критическим участком; блокироваться нужно на публичном стабильном объекте и не выполнять внутри долгий ввод-вывод. Рабочее правило: syncLock защищает общий инвариант всем методом вместе с вводом-выводом; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Рабочее правило: syncLock защищает общий инвариант коротким критическим участком; блокироваться не нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод. Рабочее правило: syncLock не защищает общий инвариант коротким критическим участком; блокироваться нужно на закрытом стабильном объекте и не выполнять внутри долгий ввод-вывод.

Вопрос 16 из 30

Раздел «Отмена»: какое утверждение позволяет предсказать поведение фрагмента по правилам Visual Basic и .NET?

Imports System.Threading
Imports System.Threading.Tasks
Module Demo
    Async Function ProcessAsync(items As IEnumerable(Of Integer), token As CancellationToken) As Task
        For Each item In items
            token.ThrowIfCancellationRequested()
            Await SaveAsync(item, token)
        Next
    End Function
End Module

Отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort является безопасным откатом. Отмена в .NET кооперативна: CancellationToken не передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Отмена в .NET принудительна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно не различают отмену от ошибки; Thread.Abort не является безопасным откатом.

Вопрос 17 из 30

Раздел «Отмена»: перед объединением правки нужно проверить один принцип. Какой именно?

Option Strict On
Imports System.Threading
Imports System.Threading.Tasks
Namespace ReviewCase21_4
    Module Demo
        Async Function ProcessAsync(reviewItems As IEnumerable(Of Integer), reviewToken As CancellationToken) As Task
            For Each reviewItem In reviewItems
                reviewToken.ThrowIfCancellationRequested()
                Await SaveAsync(reviewItem, reviewToken)
            Next
        End Function
    End Module
End Namespace

Сохранить на ревью: отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Сохранить на ревью: отмена в .NET кооперативна: CancellationToken не передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Сохранить на ревью: отмена в .NET принудительна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Сохранить на ревью: отмена в .NET кооперативна: CancellationToken передают вниз, периодически не проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Сохранить на ревью: отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно не различают отмену от ошибки; Thread.Abort не является безопасным откатом.

Вопрос 18 из 30

Раздел «Отмена»: что именно должен локализовать полезный граничный тест для этого кода?

Option Explicit On
Option Infer On
Imports System.Threading
Imports System.Threading.Tasks
Namespace BoundaryCase21_4
    Module Demo
        Async Function ProcessAsync(edgeItems As IEnumerable(Of Integer), edgeToken As CancellationToken) As Task
            For Each edgeItem In edgeItems
                edgeToken.ThrowIfCancellationRequested()
                Await SaveAsync(edgeItem, edgeToken)
            Next
        End Function
    End Module
End Namespace

Проверить на границе: отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Проверить на границе: отмена в .NET кооперативна: CancellationToken не передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Проверить на границе: отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно не различают отмену от ошибки; Thread.Abort не является безопасным откатом. Проверить на границе: отмена в .NET принудительна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Проверить на границе: отмена в .NET кооперативна: CancellationToken передают вниз, периодически не проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом.

Вопрос 19 из 30

Раздел «Отмена»: как уменьшить риск дефекта, не подменяя причину запасным значением?

Оставить в коде и тестах условие: отмена в .NET кооперативна: CancellationToken передают вниз, периодически не проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Оставить в коде и тестах условие: отмена в .NET кооперативна: CancellationToken не передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Оставить в коде и тестах условие: отмена в .NET принудительна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Оставить в коде и тестах условие: отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Оставить в коде и тестах условие: отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно не различают отмену от ошибки; Thread.Abort не является безопасным откатом.

Вопрос 20 из 30

Раздел «Отмена»: какое правило остаётся верным для современного Visual Basic?

Переносимый вывод: отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Переносимый вывод: отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort является безопасным откатом. Переносимый вывод: отмена в .NET кооперативна: CancellationToken передают вниз, периодически не проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Переносимый вывод: отмена в .NET принудительна: CancellationToken передают вниз, периодически проверяют и корректно различают отмену от ошибки; Thread.Abort не является безопасным откатом. Переносимый вывод: отмена в .NET кооперативна: CancellationToken передают вниз, периодически проверяют и корректно не различают отмену от ошибки; Thread.Abort не является безопасным откатом.

Вопрос 21 из 30

Раздел «Наблюдаемость и диагностика»: в примере с Worker важна не форма записи, а поведение. Какое утверждение его описывает?

Class Worker
    Private ReadOnly log As ILogger
    Public Async Function RunAsync(id As String) As Task
        Dim started = Stopwatch.StartNew()
        log.Info("job_start", id)
        Try
            Await ExecuteAsync(id)
            log.Info("job_ok", id, started.ElapsedMilliseconds)
        Catch ex As Exception
            log.Error("job_fail", id, ex)
            Throw
        End Try
    End Function
End Class

Гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко воспроизводит порядок. Достаточно обеспечить «один текстовый лог без контекста редко воспроизводит порядок»; условие «Гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий» можно отдельно не проверять. Гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; несколько несвязанных текстовых логов без контекста редко воспроизводит порядок. Гонки не диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко воспроизводит порядок. Гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко не воспроизводит порядок.

Вопрос 22 из 30

Раздел «Наблюдаемость и диагностика»: что должно остаться явным после переработки участка с Worker?

Option Strict On
Namespace ReviewCase21_5
    Class Worker
        Private ReadOnly log As ILogger
        Public Async Function RunAsync(reviewId As String) As Task
            Dim reviewStarted = Stopwatch.StartNew()
            log.Info("job_start", reviewId)
            Try
                Await ExecuteAsync(reviewId)
                log.Info("job_ok", reviewId, reviewStarted.ElapsedMilliseconds)
            Catch reviewEx As Exception
                log.Error("job_fail", reviewId, reviewEx)
                Throw
            End Try
        End Function
    End Class
End Namespace

Зафиксировать в ревью: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко не воспроизводит порядок. Зафиксировать в ревью: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко воспроизводит порядок. Зафиксировать в ревью: гонки не диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко воспроизводит порядок. Зафиксировать в ревью: достаточно обеспечить «один текстовый лог без контекста редко воспроизводит порядок»; условие «Гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий» можно отдельно не проверять. Зафиксировать в ревью: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; несколько несвязанных текстовых логов без контекста редко воспроизводит порядок.

Вопрос 23 из 30

Раздел «Наблюдаемость и диагностика»: для фрагмента с Worker добавляют регрессионный тест. Какой контракт он должен защищать?

Option Explicit On
Option Infer On
Namespace BoundaryCase21_5
    Class Worker
        Private ReadOnly log As ILogger
        Public Async Function RunAsync(edgeId As String) As Task
            Dim edgeStarted = Stopwatch.StartNew()
            log.Info("job_start", edgeId)
            Try
                Await ExecuteAsync(edgeId)
                log.Info("job_ok", edgeId, edgeStarted.ElapsedMilliseconds)
            Catch edgeEx As Exception
                log.Error("job_fail", edgeId, edgeEx)
                Throw
            End Try
        End Function
    End Class
End Namespace

Закрепить тестом: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко воспроизводит порядок. Закрепить тестом: гонки не диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко воспроизводит порядок. Закрепить тестом: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко не воспроизводит порядок. Закрепить тестом: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; несколько несвязанных текстовых логов без контекста редко воспроизводит порядок. Закрепить тестом: достаточно обеспечить «один текстовый лог без контекста редко воспроизводит порядок»; условие «Гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий» можно отдельно не проверять.

Вопрос 24 из 30

Раздел «Наблюдаемость и диагностика»: какой подход сохраняет границу ответственности и делает отказ диагностируемым?

Оставить в коде и тестах условие: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; несколько несвязанных текстовых логов без контекста редко воспроизводит порядок. Оставить в коде и тестах условие: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко воспроизводит порядок. Оставить в коде и тестах условие: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко не воспроизводит порядок. Оставить в коде и тестах условие: достаточно обеспечить «один текстовый лог без контекста редко воспроизводит порядок»; условие «Гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий» можно отдельно не проверять. Оставить в коде и тестах условие: гонки не диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко воспроизводит порядок.

Вопрос 25 из 30

Что точнее всего описывает механизм «Наблюдаемость и диагностика»?

Технически точный принцип: достаточно обеспечить «один текстовый лог без контекста редко воспроизводит порядок»; условие «Гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий» можно отдельно не проверять. Технически точный принцип: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко не воспроизводит порядок. Технически точный принцип: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; несколько несвязанных текстовых логов без контекста редко воспроизводит порядок. Технически точный принцип: гонки диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко воспроизводит порядок. Технически точный принцип: гонки не диагностируют по идентификаторам операций, времени ожидания, размеру очереди и взаимосвязи событий; один текстовый лог без контекста редко воспроизводит порядок.

Вопрос 26 из 30

Посмотрите на фрагмент по теме «Надёжность в эксплуатации». Какое объяснение точнее всего связывает код с его поведением?

Class WorkQueue
    Private ReadOnly queue As New BlockingCollection(Of WorkItem)(100)
    Public Function TryEnqueue(item As WorkItem) As Boolean
        Return queue.TryAdd(item, millisecondsTimeout:=250)
    End Function
    Public Sub Complete()
        queue.CompleteAdding()
    End Sub
End Class

Контракт кода: достаточно явно обеспечить «Рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ»; требование «а также имеет способ мягко остановить приём новой работы перед завершением» на поведение не влияет. Контракт кода: рабочая система не ограничивает очередь и параллелизм, переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением. Контракт кода: рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением. Контракт кода: в разделе Надёжность в эксплуатации выполнение «Рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ» означает, что среда автоматически обеспечивает «а также имеет способ мягко остановить приём новой работы перед завершением». Контракт кода: рабочая система ограничивает очередь и параллелизм, не переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением.

Вопрос 27 из 30

Раздел «Надёжность в эксплуатации»: перед объединением правки нужно проверить один принцип. Какой именно?

Option Strict On
Namespace ReviewCase21_6
    Class WorkQueue
        Private ReadOnly queue As New BlockingCollection(Of WorkItem)(101)
        Public Function TryEnqueue(reviewItem As WorkItem) As Boolean
            Return queue.TryAdd(reviewItem, millisecondsTimeout:=251)
        End Function
        Public Sub Complete()
            queue.CompleteAdding()
        End Sub
    End Class
End Namespace

Зафиксировать в ревью: в разделе Надёжность в эксплуатации выполнение «Рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ» означает, что среда автоматически обеспечивает «а также имеет способ мягко остановить приём новой работы перед завершением». Зафиксировать в ревью: достаточно явно обеспечить «Рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ»; требование «а также имеет способ мягко остановить приём новой работы перед завершением» на поведение не влияет. Зафиксировать в ревью: рабочая система не ограничивает очередь и параллелизм, переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением. Зафиксировать в ревью: рабочая система ограничивает очередь и параллелизм, не переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением. Зафиксировать в ревью: рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением.

Вопрос 28 из 30

Какое свойство механизма «Надёжность в эксплуатации» нужно проверить на редком, но допустимом сценарии?

Option Explicit On
Option Infer On
Namespace BoundaryCase21_6
    Class WorkQueue
        Private ReadOnly queue As New BlockingCollection(Of WorkItem)(99)
        Public Function TryEnqueue(edgeItem As WorkItem) As Boolean
            Return queue.TryAdd(edgeItem, millisecondsTimeout:=249)
        End Function
        Public Sub Complete()
            queue.CompleteAdding()
        End Sub
    End Class
End Namespace

Добавить регрессионную проверку: рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением. Добавить регрессионную проверку: рабочая система не ограничивает очередь и параллелизм, переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением. Добавить регрессионную проверку: достаточно явно обеспечить «Рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ»; требование «а также имеет способ мягко остановить приём новой работы перед завершением» на поведение не влияет. Добавить регрессионную проверку: в разделе Надёжность в эксплуатации выполнение «Рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ» означает, что среда автоматически обеспечивает «а также имеет способ мягко остановить приём новой работы перед завершением». Добавить регрессионную проверку: рабочая система ограничивает очередь и параллелизм, не переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением.

Вопрос 29 из 30

Раздел «Надёжность в эксплуатации»: что нужно сделать частью контракта рабочего модуля?

Закрепить рабочее решение: в разделе Надёжность в эксплуатации выполнение «Рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ» означает, что среда автоматически обеспечивает «а также имеет способ мягко остановить приём новой работы перед завершением». Закрепить рабочее решение: рабочая система ограничивает очередь и параллелизм, не переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением. Закрепить рабочее решение: рабочая система не ограничивает очередь и параллелизм, переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением. Закрепить рабочее решение: достаточно явно обеспечить «Рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ»; требование «а также имеет способ мягко остановить приём новой работы перед завершением» на поведение не влияет. Закрепить рабочее решение: рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением.

Вопрос 30 из 30

Раздел «Надёжность в эксплуатации»: какой вывод описывает семантику, а не предпочтение в оформлении?

Надёжное обобщение: в разделе Надёжность в эксплуатации выполнение «Рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ» означает, что среда автоматически обеспечивает «а также имеет способ мягко остановить приём новой работы перед завершением». Надёжное обобщение: достаточно явно обеспечить «Рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ»; требование «а также имеет способ мягко остановить приём новой работы перед завершением» на поведение не влияет. Надёжное обобщение: рабочая система ограничивает очередь и параллелизм, не переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением. Надёжное обобщение: рабочая система ограничивает очередь и параллелизм, переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением. Надёжное обобщение: рабочая система не ограничивает очередь и параллелизм, переживает повтор и частичный отказ, а также имеет способ мягко остановить приём новой работы перед завершением.