EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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 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
<== Date ==> <== Thread ==>

Subject: Re: PVXS monitor - No dependence on MPMCFIFO workqueue
From: Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>
To: Eusebio Naif Al-Soliman Fuentes <eunaif at correo.ugr.es>
Cc: Tech Talk <tech-talk at aps.anl.gov>
Date: Mon, 15 Apr 2024 12:17:53 -0700
On 4/15/24 01:49, Eusebio Naif Al-Soliman Fuentes via Tech-talk wrote:
...
The problem is that the ".event()" requires a lambda function with a specific definition and it doesn't let me make calls to class methods or pass arguments to the lambda. Is there a way to do that?

Please first have a look at the Threading and Ownership sections.

https: //mdavidsaver.github.io/pvxs/client.html#threading

Use of MPMCFIFO, or a similar work offloading queue, is not required.
Have a look at the C++ syntax for lambda capture expressions.  My
example in the Ownership section demonstrates capturing a shared_ptr,
which would allow method calls through that instance.

[1] https: //en.cppreference.com/w/cpp/language/lambda#Lambda_capture


The reason to do this is because my code requires time to be executed and the MPMCFIFO workqueue fills up quickly.

I would strongly encourage use of MPMCFIFO in this situation.

If your application is very simple, only a single subscription, then
doing as you describe would not have much consequence.

Moving work directly to the event() callback will not change the time
that code needs to execute.  However, your code would then be running on
an internal PVXS worker thread should be performing network I/O.


A couple of questions:

Have you checked that the time needed to process a single subscription
update is less than the interval between updates?

Is this always true, or only on average?

If only on average, would a larger subscription buffer be enough?

Are you working with multiple subscriptions?

The acronym MPMC is Multiple Producer, Multiple Consumer.  The examples
currently in PVXS show a single consumer.  If your task is something
CPU intensive, then it may make sense for you to have a number of
consumers equal to the number of CPU cores.

Multiple consumers means having more than one thread concurrently
calling MPMCFIFO::pop().


References:
PVXS monitor - No dependence on MPMCFIFO workqueue Eusebio Naif Al-Soliman Fuentes via Tech-talk

Navigate by Date:
Prev: Re: AW: Readback of output variables in adsDriver Torsten Bögershausen via Tech-talk
Next: Data acquisition Pico 2406B 王鹏鹏 via Tech-talk
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: PVXS monitor - No dependence on MPMCFIFO workqueue Eusebio Naif Al-Soliman Fuentes via Tech-talk
Next: Data acquisition Pico 2406B 王鹏鹏 via Tech-talk
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
ANJ, 15 Apr 2024 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·