We noticed that the efficient mutex primitive provided by POSIX
and win32 do not implement a mutex lock with an arbitrary
timeout. Both OS had a lock with a zero length timeout (a so
called try lock primitive) in their efficient mutex primitive.
Since there is quite a bit of locking in certain parts of base
then the proper selection of an efficient mutex primitive has a
big impact on the overall performance of EPICS.
We could have implemented a high level portable mutex primitive
with a timeout by allocating both a low level mutex and an event
semaphore for each high level mutex. This was tried on one OS as
a proof of principal universal mutex primitive, but in the end it
was decided to drop support for the mutex lock with timeout
feature so that we could realize the performance improvements
associated with the low level mutex primitives while avoiding the
additional overhead associated with the allocation of an
additional event semaphore for each mutex.
So for your situation there are several alternatives:
1) You implement a situation specific try lock loop with a sleep
and a timeout embedded in it. This isn't very responsive to
changes in the mutex state and could fail in situations where
there is a high mutex duty factor. Nevertheless, it *was* decided
that this would be sufficient in the situation surrounding one of
the diagnostics run from the shell that comes with base.
2) We implement two mutex primitives: A low overhead primitive
and a high overhead primitive with a timeout. Hopefully the high
level mutex could be implemented purely in OS independent code.
3) You could also implement some application specific variation
of (2) yourself.
Jeff
> -----Original Message-----
> From: Allison, Stephanie [mailto:[email protected]]
> Sent: Monday, April 14, 2003 10:53 AM
> To: '[email protected]'
> Subject: epicsMutexLockWithTimeout not supported in 3.14.1
>
> Hello -
>
> We use two device/driver support packages here at SSRL that
> require
> the functionality of epicsMutexLockWithTimeout which is no
> longer supported
> in 3.14.1. In ipac, it's only needed by the canRead diagnostic
> routine so I simply
> used the same logic I found in epics base/src/db/dbLock.c which
> does a little
> loop with try/wait. But in ether_ip, this functionality is a
> key part of the support.
>
> There was discussion about this in core-talk and a few
> sentences in the 3.14.1
> release notes, but it's not clear the best way to port from
> epicsMutexLockWithTimeout
> (or vxWorks semTake with a non-WAIT_FOREVER timeout) to
> something
> equivalent.
>
> Any suggestions? Thank you,
>
> Stephanie Allison
> SSRL/SLAC
- References:
- epicsMutexLockWithTimeout not supported in 3.14.1 Allison, Stephanie
- Navigate by Date:
- Prev:
Re: epicsMutexLockWithTimeout not supported in 3.14.1 Kay-Uwe Kasemir
- Next:
Re: how to prevent ioc app from being built for both target and host? Till Straumann
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
epicsMutexLockWithTimeout not supported in 3.14.1 Allison, Stephanie
- Next:
Re: epicsMutexLockWithTimeout not supported in 3.14.1 Kay-Uwe Kasemir
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|