Home Help Center

QNX port

n2503vn2503v Member Alex MakarenkoOrganization: ACFR, University of SydneyProject: Orca ✭✭✭
I am trying to port Ice 3.1.1 to QNX real time OS. It now has gcc 3.3.5 so it wasn't too hard. Everything compiles now but some tests fail.

The biggest problem is that in QNX, pthread_cond_wait() apparently cannot be used with recursive mutexes. "Recursive mutexes are non-POSIX services - they don't work with condvars."

So IceUtil::Monitor<IceUtil::Mutex> works fine but using IceUtil::Monitor<IceUtil::RecMutex> fails (an exception is thrown from line 208 of Cond.h). I wouldn't care about it in my own code, but ObjectAdapterI uses this pattern which makes it somewhat important. :)

I know this platform is not supported but if somebody could point me in the right direction it'd be great.

(I saw a possibly related post by Benoit from a long time ago but it talks about signalling a condvar without locking the mutex which could also be an issue. http://zeroc.com/vbulletin/showthread.php?t=69)

thanks, alex


  • michimichi Member Michi HenningOrganization: Triodia TechnologiesProject: I have a passing interest in Ice :-) ✭✭✭
    I would suggest to build your own recursive mutex in that case, replacing the IceUtil::RecMutex one. Use an ordinary mutex for the implementation and keep track of the identity of the locker. If the mutex is already locked by the locker, return from the lock() call after incrementing a lock count; in unlock(), decrement the lock count, and when it reaches zero, unlock the non-recursive mutex. If the lock() caller doesn't hold the mutex, and the mutex is locked, put the caller to sleep and wake him up when the mutex becomes available.


  • n2503vn2503v Member Alex MakarenkoOrganization: ACFR, University of SydneyProject: Orca ✭✭✭
    Thanks Michi, I think i can do it.

    by the "identity of the locker" you mean the ID of the calling thread, is this right?

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Alex,

    Yes, using the ID of the calling thread will work! You can either use the pthread_t directly (but make sure to use pthread_equal to compare two pthread_t) or better, you could use the IceUtil::ThreadControl class to identify the thread, see the Ice manual for more information on this class.

  • n2503vn2503v Member Alex MakarenkoOrganization: ACFR, University of SydneyProject: Orca ✭✭✭
    Ok, got it to work. cool!

    i'm using pthread_self(), copied most of it from Benoit's MacOS X patch from 2003. all Ice and IceUtil tests check out. Still having problems with run-time linking to dependencies (SSL, DB), but i can probably fix it eventually.

    I was going to post a patch but want to ask ZeroC guys first if the next release is in the pipeline. can you tell me if it's days, weeks, months? if it's "days", i would wait, don't want to do this job twice in one week. :)

    cheers, alex
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    It's definitely not days. Next year! :)
Sign In or Register to comment.