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

У меня есть код моего приложения, в котором используется boost inteprocess scoped lock with timers. Когда мьютекс получен в одном потоке, связывание второго потока для его получения на несколько миллисекунд завершится ошибкой и будет записывать что-то для просмотра.

Не знаю почему, но с версией boost 1.50 это больше не работает. В приведенном ниже коде я вижу, что поток № 2 не печатает «ERROR», но полностью завис.

Я что-то упустил?

Я использую ядро ​​LINUX 2.6.32 с g ++.

Может быть, что-то связано с UTC? Я прочитал o boost, что время, используемое такой блокировкой, - это UTC, а в режиме даты я читаю прямо сейчас о local_adjustor и преобразовании из локального в utc и наоборот.

AFG

   #include <iostream>
   #include <boost/interprocess/sync/scoped_lock.hpp>
   #include <boost/date_time/posix_time/posix_time.hpp>
   #include <boost/interprocess/sync/named_mutex.hpp>
   #include <boost/thread.hpp>
   #include <boost/bind.hpp>

   namespace bi = boost::interprocess;


   void  lock_test( bi::named_mutex& mt, bool long_sleep ) { 

           boost::posix_time::ptime pt = 
             boost::posix_time::microsec_clock::local_time()
             +  boost::posix_time::milliseconds(100);

            bi::scoped_lock<bi::named_mutex> l( mt, pt );
            if( l.owns() ){
            std::cout << "Locked"<<std::endl;
            }
            else{
            std::cout << "ERROR" << std::endl;
            std::cout.flush();
            return ;
            }

            if(long_sleep){
                while(true) {sleep(1);std::cout<<"[]";std::cout.flush();}
            }
        }

        int main(){

               bi::named_mutex  m_mutex( bi::open_or_create, "ciao"
               , bi::permissions( 0666  ));
               boost::thread t1 = boost::thread( &lock_test
               , boost::ref( m_mutex), true );
               sleep(4);
               boost::thread t2 = boost::thread(  &lock_test
               , boost::ref(m_mutex), false );
               while(true){sleep(1);}
        }

person Abruzzo Forte e Gentile    schedule 04.09.2012    source источник
comment
Вы не сказали, какую платформу вы используете, но на * NIX вы можете использовать strace, dtrace, truss или что-то подобное, чтобы узнать, какие аргументы передаются примитивам системной синхронизации и где ваши потоки заблокированы.   -  person Useless    schedule 04.09.2012
comment
Я обновил свой пост. Я использую LINUX. С помощью strace я вижу, что наносон вызывается постоянно.   -  person Abruzzo Forte e Gentile    schedule 04.09.2012
comment
Похоже, scoped_lock должен использовать либо sem_timedwait, либо sem_trywait с циклом yield, если BOOST_INTERPROCESS_POSIX_TIMEOUTS макрос не определен. Можете ли вы сказать, что используется и определен ли этот макрос?   -  person Useless    schedule 04.09.2012
comment
ПРИВЕТ. Я ddebugged, и код использует sem_timedwait с определенным BOOST_INTERPROCESS_POSIX_TIMEOUTS.   -  person Abruzzo Forte e Gentile    schedule 04.09.2012
comment
Похоже, что если я переключусь с boost :: posix_time :: microsec_clock :: local_time () на boost :: posix_time :: microsec_clock :: universal_time (), все будет работать нормально.   -  person Abruzzo Forte e Gentile    schedule 04.09.2012
comment
Не стесняйтесь отвечать на свой вопрос - он все равно может помочь кому-то другому!   -  person Useless    schedule 04.09.2012
comment
Я могу это сделать, но мне нужен кто-нибудь, кто подтвердит, что это действительно правильное решение. Кто-нибудь может это подтвердить?   -  person Abruzzo Forte e Gentile    schedule 04.09.2012


Ответы (2)


Похоже, что если я переключусь с boost::posix_time::microsec_clock::local_time() на

 boost::posix_time::microsec_clock::universal_time() 

все работает нормально.

person Abruzzo Forte e Gentile    schedule 05.09.2012

Вам следует использовать boost::get_system_time(), примеров с ним довольно много. Хотя я не могу найти авторитетный источник, я использую microsec_clock точно так же, как и вы, и сталкиваюсь с аналогичными проблемами. Только что обнаружил ошибку, обновлю, когда я протестирую исправление.

Использование boost :: unique_lock :: timed_lock

person ansgri    schedule 15.08.2014