The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
rfork и синхронизация процессов, !*! Andrew, 22-Янв-07, 14:57  [смотреть все]
Приветствую всех.

Подскажите, пожалуйста, что можно использовать для синхронизации процессов созданных при помощи rfork() во FreeBSD?
Нужны такие средства синхронизации как mutex, cond var, rwlocks.

Спасибо.

  • rfork и синхронизация процессов, !*! BigHo, 15:23 , 22-Янв-07 (1)
    >Приветствую всех.
    >
    >Подскажите, пожалуйста, что можно использовать для синхронизации процессов созданных при помощи rfork()
    >во FreeBSD?
    >Нужны такие средства синхронизации как mutex, cond var, rwlocks.


    наверное также, как и при работе с потоками. Посмотри rfork_thread(3).

    • rfork и синхронизация процессов, !*! Andrew, 15:30 , 22-Янв-07 (2)
      >>Приветствую всех.
      >>
      >>Подскажите, пожалуйста, что можно использовать для синхронизации процессов созданных при помощи rfork()
      >>во FreeBSD?
      >>Нужны такие средства синхронизации как mutex, cond var, rwlocks.
      >
      >
      >наверное также, как и при работе с потоками. Посмотри rfork_thread(3).

      rfork_thread() это создание процесса, надстройка над rfork().
      функции для работы с потоками pthread_*() не работают.

      • rfork и синхронизация процессов, !*! BigHo, 16:30 , 22-Янв-07 (3)
        >rfork_thread() это создание процесса, надстройка над rfork().

        так оно и есть. Только если будешь использовать чистый rfork с флагом RFMEM, то рискуешь загубить стек.

        >функции для работы с потоками pthread_*() не работают.

        Вообще то должны. Ты проверял ?

        Хотя если ты имел в виду не rfork, а скорее некоторую версию, приближенную к fork, то посмотри в сторону mmap и её опцию MAP_HASSEMAPHORE.

        • rfork и синхронизация процессов, !*! Andrew, 20:58 , 22-Янв-07 (4)
          >>rfork_thread() это создание процесса, надстройка над rfork().
          >
          >так оно и есть. Только если будешь использовать чистый rfork с флагом
          >RFMEM, то рискуешь загубить стек.

          я использую rfork_thread().
          в доке написано, что rfork(RFMEM) вообще нереально самому реализовать.

          >
          >>функции для работы с потоками pthread_*() не работают.
          >
          >Вообще то должны. Ты проверял ?

          Да, проверял с разными либами - не пашет.
          Либо просто не работает, либо страшно глючит (через раз), либо падает.

          >Хотя если ты имел в виду не rfork, а скорее некоторую версию,
          >приближенную к fork, то посмотри в сторону mmap и её опцию
          >MAP_HASSEMAPHORE.

          Не хочу сам все писать, хочу уже готовые решения найти. Велик в такой ситуации изобретать не нужно.

          • rfork и синхронизация процессов, !*! BigHo, 21:27 , 22-Янв-07 (5)
            >Не хочу сам все писать, хочу уже готовые решения найти. Велик в
            >такой ситуации изобретать не нужно.

            Чем тогда не понравились /usr/ports/devel/linuxthreads и /usr/ports/devel/ngpt ?

            • rfork и синхронизация процессов, !*! Andrew, 02:17 , 24-Янв-07 (6)
              >>Не хочу сам все писать, хочу уже готовые решения найти. Велик в
              >>такой ситуации изобретать не нужно.
              >
              >Чем тогда не понравились /usr/ports/devel/linuxthreads и /usr/ports/devel/ngpt ?

              Спасибо. Посмотрел.
              В принципе вполне юзабильно, только сравнив скорость получилось что собственные mutex, condvar работают быстрее чем из linuxthreads - это обидно :(

              • rfork и синхронизация процессов, !*! BigHo, 11:43 , 24-Янв-07 (7)
                >Спасибо. Посмотрел.
                >В принципе вполне юзабильно, только сравнив скорость получилось что собственные mutex, condvar
                >работают быстрее чем из linuxthreads - это обидно :(

                В linuxthreads требование к скорости не является принципиальным. Во главу угла ставится совместимость. Так же как и обычные pthread* функции пытаясь соответствовать POSIX, сильно распухли кодом, и как следствие - понижение производительности. Думаю, если выполнить все требования для соответствия POSIX, скорость работы заметно поубавится :)

                P.S. Не совсем понимаю необходимость использования rfork, если есть нормальные потоки.

                • rfork и синхронизация процессов, !*! Andrew, 16:23 , 24-Янв-07 (8)
                  >>Спасибо. Посмотрел.
                  >>В принципе вполне юзабильно, только сравнив скорость получилось что собственные mutex, condvar
                  >>работают быстрее чем из linuxthreads - это обидно :(
                  >
                  >В linuxthreads требование к скорости не является принципиальным. Во главу угла ставится
                  >совместимость. Так же как и обычные pthread* функции пытаясь соответствовать POSIX,
                  >сильно распухли кодом, и как следствие - понижение производительности. Думаю, если
                  >выполнить все требования для соответствия POSIX, скорость работы заметно поубавится :)
                  >
                  >
                  >P.S. Не совсем понимаю необходимость использования rfork, если есть нормальные потоки.

                  Необходимость работы на SMP системах.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру