sched_yield не работает?

А что sched_yield возвращает? Или она отрабатывает без ошибок?

sched_yield не гарантирует, что следующим запуститься твой второй поток. он просто завершает тайм-слайс текущего потока, решение, какой поток выполнять дальше, выполняет планировщик. при этом он вполне может выбрать даже тот же поток.

А какой ресурс лочится мьютексом?

очень плохая музыкаое решение. если нужна синхронная работа - используй два семафора.

Вы не понимаете, как работает sched_yield. Он делает ровно то, что и должен делать. Просто сама семантика sched_yield не имеет четкого смысла (если только для процесса не установлен планировщик SCHED_RR). Вам следует четко понять, чего вы хотите добиться и выбрать соответствующий механизм синхронизации.

>при этом он вполне может выбрать даже тот же поток.

Если используется планировщик CFS, то это очень даже вероятно.

На линухах он всегда 0 возвращает. Так в манах написано, да я другого и не видел

Соединение с БД. libpqxx мы используем

Нужно, чтобы один тред почти постоянно владел ресурсом, но в то же время, другой мог бы легко его получить. Поэтому мы так и делали: лочили, немного работали, возвращали, пытались переключить поток...

Гм... в манах написано, что он переставляет текущий поток в конец очереди планирования

Посмотри в сырцах, там когда CFS прикручивали что-то мудрили с этим системным вызовом. Как минимум я вижу архивы lkml на эту тему.

> в манах написано, что он переставляет текущий поток в конец очереди планирования

Это была деталь реализации, на которую не следовало полагаться. И, наверное, старые маны.

> переставляет текущий поток в конец очереди планирования

Если включишь планировщик FIFO, то так и должно быть. В дефолтном планировщике никто не обещает наличие очереди вообще :)

Лучше что-бы тред висел на семафоре и ждал сигнала от другого треда, когда ему можно проснутся и работать. То есть добавить туда события через sem_post()/sem_wait().

Соединение с БД. libpqxx мы используем

Можно попробовать использовать condition'ы.

man pthread_cond_wait, pthread_cond_signal, pthread_cond_broadcast или их аналоги в уже используемой библиотеке (типа boost), если что-то используете.

я бы придумал какой-нибудь сигнализатор, сразу в голову правда ничего особенного не приходит кроме cond_wait & cond_signal, думать надо. да и вооще

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

ты не находишь здесь противоречия? думаю «легко» не получится.

Понятно, значит sched_yield и правда кака... Придется по другому задачу решать.

Если у кого-нибудь идеи есть, буду рад. Задача такая: Есть соединение с БД. Первый тред слушает события постгреса(NOTIFY). Для этого ему нуже коннекшен. Но этот же коннекшен может понадобится в другом треде, чтобы select сделать. Т.е. получается, что первый тред взял ненадолго коннекшен, проверил, есть ли NOTIFY от постгреса, и вернул коннекшен. Если он никому не нужен, то опять взял его себе и проверил наличие notify.

В общем, мысль у меня сейчас такая: обложить мьютексом не сам коннекшен, а некую переменную dbConnectionUsed и с делать wait/signal

перечитал несколько раз… на кой овощ нужен первый тред я так и не понял.

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

Что такое LISTEN/NOTIFY в PostreSQL знаешь? Вот чтобы колбэки внутри программы дергать, когда случился евент, первый тред и нужен

В общем, вот, набросал на коленке. Вроде как работает, может, кому пригодится:

  template <class T>
  class resource_holder
  {
    public:
      resource_holder(T* r = NULL) : _resource(r), _is_used(false){}

      void reset(T* nr)
      {
        _resource.reset(nr);
      }

      T* get()
      {
        _mtx.lock();
        if( _is_used )
          _cond.wait(_mtx);
        _is_used = true;
        _mtx.unlock();

        return _resource.get();
      }

      void free()
      {
        _mtx.lock();
        _is_used = false;
        _cond.notify();
        _mtx.unlock();
      }

    private:
      mutex _mtx;
      cond _cond;
      std::auto_ptr<T> _resource;
      bool _is_used;
  };

Хотя нет... та же проблема, хоть и значительно реже. Видимо, так и придется оставить костылик в виде usleep(1)

Сделай прокси объект. Когда надо с базой работать - он просто дублирует команды, а когда приходять уведомления, он сигнализирует тем, кто подписан. Тривиально не получится, зато будет работать.