Hi Ralph,
On 2012-10-18 Ralph Lange wrote:
> > BTW, if pthread_spin_lock() is not implemented, using a native
> > pthread_mutex_t might be lighter weight than an epicsMutex object.
>
> On Posix, yes. (Only slightly though, as the Posix implementation of
> epicsMutex uses pthread_mutex_t.)
The *second* implementation in osi/posix/osdMutex.c (for Posix OSs where
PTHREAD_MUTEX_RECURSIVE is not available) is where it will make more of a
difference, and that is more likely to be used where pthread_spin_lock() is
not available. Not as important though I agree.
> The Default should be epicsMutex, to make things work on Windows etc.
> until specific implementations are in place.
At the moment most target builds (other than self-hosted Windows) search the
os/posix source directories for files before os/default, so you can't rely on
the os/default implementation being used if there is an os/posix one. This is
a bit stupid, but I haven't tried setting POSIX=NO in the vxWorks or RTEMS
target configuration files so I don't know how hard that might be to change.
Thanks,
- Andrew
--
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte
- Replies:
- Re: RFC: libCom/osi - new spinlock API Ralph Lange
- References:
- RFC: libCom/osi - new spinlock API Ralph Lange
- Re: RFC: libCom/osi - new spinlock API Andrew Johnson
- Re: RFC: libCom/osi - new spinlock API Ralph Lange
- Navigate by Date:
- Prev:
Re: RFC: libCom/osi - new spinlock API Ralph Lange
- Next:
Re: RFC: libCom/osi - new spinlock API Ralph Lange
- Index:
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:
Re: RFC: libCom/osi - new spinlock API Ralph Lange
- Next:
Re: RFC: libCom/osi - new spinlock API Ralph Lange
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|