• Ещё больше простых багов [язык Ада]

    • Перевод

    (Many) More Low Hanging Bugs


    Примечание переводчика. На Хабре практически полностью отсутствуют публикации, связанные с языком Ада. А ведь это — живой язык, на котором пишут программы, для которого разрабатываются инструменты статического анализа. Чтобы хоть немного заполнить этот информационный вакуум на Хабре, я решил перевести небольшую заметку, связанную с данным языком. Почему её? В ней упоминается PVS-Studio, и мне это приятно :). Плюс, возможно, российские разработчики на языке Ada узнают о новом для себя инструментарии и увидят, что они совсем не одиноки, и жизнь продолжает кипеть в мире Ада.
    Читать дальше →
    • +22
    • 6,2k
    • 5
  • Обзор примитивов синхронизации — спинлоки и тайны ядра процессора

      Последняя статья про классические примитивы синхронизации.

      (Наверное, потом напишу ещё одну про совсем уже нетипичную задачу, но это потом.)

      Сегодня мы немножко заглянем в процессор. Чуть-чуть.

      По сути, мы будем говорить про единственный примитив, который принципиально отличается от остальных: спинлок. Spinlock.

      В комментариях к предыдущим заметкам возникла дискуссия — насколько справедливо вообще выделять спинлок как примитив, ведь по сути он — просто мьютекс, верно? Он выполняет ту же функцию — запрещает одновременное исполнение фрагмента кода несколькими параллельными нитями.

      На уровне процесса всё так и есть — различия между спинлоком и мьютексом — чисто технические, вопрос реализации и производительности.

      Но меня эта тема интересует не только с позиции программиста юзерленда, но и с позиции разработчика ядра, а так же и разработчика самих примитивов синхронизации. И тут уже различие принципиально.

      Дело в том, что внутри ядра мьютекс реализован с помощью спинлоков, а вот спинлоки реализованы сами по себе, автономно. Они — действительно базовый примитив. Ниже — только сам процессор.

      Есть и ещё одно, семантическое различие. Мьютекс допускает и предполагает снятие нити с процессора, долгую остановку вызывающей нити. Мьютексом можно запереть объект на час или сутки, это приемлемо и нормально. Спинлок принципиально рассчитан только на кратчайшие приостановки, это всегда работа с неатомарным стейтом объекта. Присваивание группы переменных, небольшой цикл — это максимум того, что можно сделать под спинлоком.

      Итак, иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором. Мы в них немного заглянем сегодня.

      Как устроен спинлок?
      Читать дальше →
    • Обзор примитивов синхронизации — Семафор и немного lockless-а

        В прошлой заметке мы обсудили самую известную пару из лагеря инструментов синхронизации тредов — mutex и cond. Сегодня встретимся с sema — примитивом, который умеет заменять предыдущие два в одиночку.

        Но сначала — пара слов о случайных пробуждениях. (Спасибо xaizek, который мне об этом напомнил.) В принципе, строго реализованные механизмы синхронизации этим не страдают, но, тем не менее, опытный программист на это никогда не полагается.

        Напомню фрагмент кода:

        while(total_free_mem <= 0)
            {
            wait_cond(&got_free_mem, &allocator_mutex);
            }
        


        Здесь цикл вокруг wait_cond гарантирует нам, что даже если мы вернёмся из ожидания события случайно или по ошибке, ничего страшного не случится — проверка в while обеспечит нам уверенность, что нужное состояние проверяемого объекта достигнуто. Если нет — поспим ещё в ожидании.

        Отметим ещё раз, что проверяем мы состояние объекта (total_free_mem <= 0) при запертом мьютексе, то есть никто не может его менять в то же самое время.
        Читать дальше →
      • Обзор примитивов синхронизации — mutex и cond

          Синхронизация нужна в любой малтитредной программе. (Если, конечно, она не состоит из локлесс алгоритмов на 100%, что вряд ли). Будь то приложение или компонента ядра современной операционной системы.

          Меня всё нижесказанное, конечно, больше волнует с точки зрения разработки ядра ОС. Но почти всё применимо и к пользовательскому коду.

          Кстати, ядра старых ОС в примитивах синхронизации не нуждались, поскольку преемптивной мультизадачности внутри ядра в старые добрые времена не было. (Уж за Юникс 7-й версии я отвечаю. Не было.) Точнее, единственным методом синхронизации был запрет прерываний. Но об этом позже.

          Сначала перечислим героев. Мне известны следующие примитивы синхронизации:

          User/kernel mode: mutex+cond, sema, enter/leave critical section.
          Kernel only: spinlock, управление прерываниями.

          Зачем всё это нужно, читатель, наверное, знает, но всё же уточним.

          Если некоторая структура данных может быть доступна двум параллельно работающим нитям (или нити и прерыванию), и являет собой сущность, к которой нельзя обеспечить атомарный доступ, то работу с такой структурой нужно производить так, чтобы только одна нить одновременно выполняла сложные манипуляции с состоянием структуры.
          Читать дальше →
        • Lua что новенького в BitTorrent DHT?

            Какое-то время назад я написал для Shareaza внешний DHT Tracker на Lua (GitHub). Для Shareaza это обычный локальный трекер, а по сути это BitTorrent DHT клиент, который позволяет ей качать торенты по магнет ссылкам без трекера.

            Так вот, пока клиент работает, он отлавливает пакеты с неизвестными ему полями и сохраняет для дальнейшего анализа (если опция включена).

            Итак, что новенького мы наловили в BitTorrent DHT.
            Читать дальше →
          • Как правильно качать в p2p сетях или магнит с битрейтом

              Раз уж пошла такая пляска, то и я расскажу про новый параметр магнет ссылки.

              br=192000
              



              В магнет-ссылке он выглядит так.

              magnet:?dn=pop_music.mp3...&br=192000
              

              Этот параметр позволяет совместить преимущества последовательного и случайного выбора частей для загрузки. Назовем это «смешанный способ выбора частей». Тем самым давая возможность «онлайн» просмотра/прослушивания без ущерба для скорости загрузки.
              Подробности
            • Новый параметр описания раздачи &x.do= в магнет-ссылке для FlylinkDC++. Факторы выбора юзером файлообменной сети

                Прочитав заголовок статьи многие подумали, что первая часть не имеет никакого отношения ко второй части. Однако, ниже я приведу примеры которые показывают тесную взаимосвязь многих обстоятельств — и как итог выбор пользователем определённой файлообменной сети.
                Читать дальше →
              • Приручение файлообменных P2P сетей. DC (Direct Connect). Часть 2

                  С момента первой публикации программы MediaDC на этом сайте прошло не много времени, но уже сейчас можно сказать, что программа вызывает интерес.

                  Вкратце, программа представляет собой средство для просмотра файлов (фильмов, музыки, картинок) по протоколу DC (Direct Connect).
                  Таким образом, можно не скачивая оценить контент и избежать разочарования от потерянного времени на скачивание не интересного (в плохом качестве, etc) фильма.

                  Программа задумана для стирания грани между локальными файлами и файлами доступными в DC, по подобию обычной (SMB, Netbios шары).
                  Более детальное описание можно найти в моем первом посте Приручение файлообменных P2P сетей. DC (Direct Connect).

                  Прототип программы можно увидеть тут MediaDC Прошу учесть, сайт программы, как и видео, показанное на его страницах, изначально были разработаны с расчетом на конкретную локальную сеть, с ее специфическими настройкой и аудиторией и не предполагался выход в Internet.

                  Читать дальше →
                • EiskaltDC++. Первый релиз под номером 2.0

                    Совсем недавно состоялся первый релиз нововго DC++ клиента для Linux — EiskaltDC++ 2.0. Проект разрабатывается нашими соотечественниками и является прямым наследником EiskaltDC. Выход сразу версии 2.0 связан с тем, что был осуществлен переход на ядро dc++ (EiskaltDC был основан на dclib), код был полностью переписан, новый интерфейс основан на Qt4 и внешне максимально приближен к оригинальным клиентам DC++. В результате EiskaltDC++ стал представлять собой front-end на Qt4 для ядра dc++.
                    Читать дальше →
                  • Azure Service Fabric: вторые шаги


                      Снова Чарли Чаплин на фабрике в фильме «Новые времена»


                      Продолжаем разговор про Azure Service Fabric. В предыдущей статье я упомянул о планах написать сначала про stateful сервисы, а затем уже перейти к модели акторов в ASF. Концепция изменилась — подумалось мне, что неплохо бы для примеров использовать если уж не production-решение, то что-то близкое, чтобы была теоретическая польза и практический смысл. Можно объединить все компоненты ASF в одном флаконе — чтобы и корованы набигали, и лунапарк, и Винни-Пух и все-все-все. Вот с такими мыслями я и пошел на кладбище домашних проектов в поисках кандидата на оживление.


                      Читать дальше →