<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font size="-1">An idea to avoid a mutex that may block the
remaining threads.<br>
<br>
This page shows std::atomic::operator++<br>
<a class="moz-txt-link-freetext" href="http://www.cplusplus.com/reference/atomic/atomic/operatorplusplus/">http://www.cplusplus.com/reference/atomic/atomic/operatorplusplus/</a><br>
<br>
Instead of writing directly to the previously mutexed device,
get the next number from the atomic increment and write to a
memory file with that number as a name. Each process will then
write a separate file with a different incremented name. Since
filenames are handled as strings we may want to, say, add a
large number to the increment in order to have time sequenced
files by name with all names having the same number of digits.
This is not the only way to get a file ordering but is an
example. Alternatively, on Linux we might use ls -1t *.<br>
<br>
At this point there is no waiting for the multiple threads.<br>
<br>
Now we need a thread to read the files in order to feed the
device. If we want to cut out the slack time between files for
finding, opening, closing, deleting, we can ping-pong between
two coordinated processes where the second has the next file
ready to go when the first process yields the device.<br>
<br>
There are obvious issues with the above, for example, one being
that the throughput of the device is slower than the combined
throughput of the threads, another being wraparound on file
numbering.<br>
<br>
The first issue is the throughput ratio between the device and
the number of threads. The ratio should be evenly balanced
around 1.0. This suggests that the number of threads can be
moved up and down to obtain the best balance, with perhaps some
sufficient volume of data pending to avoid any device slack
time.<br>
<br>
Also with a little effort we can read, for sending to the
device, a file that is being written by a process in order to
avoid an initial device utilization delay, if that becomes
useful. But that should only be an issue for the first one or
two files.</font></p>
<p><font size="-1">Neil Nelson<br>
</font></p>
<div class="moz-cite-prefix"><font size="-1">On 7/2/19 1:13 PM,
Billy O'Mahony via cfe-dev wrote:<br>
</font></div>
<blockquote type="cite"
cite="mid:CAEHc-tV67OO3Zf-y4PLe1gPo3Vzdsgm4mGq6=_d4OMeWXGA8Xg@mail.gmail.com"><font
size="-1">
</font>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div><font size="-1">Hello,</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1">I'd like to write a rule for either
clang-tidy or static analyzer to help catch some potential
errors in a project I'm working on.</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1">My questions are: <br>
</font></div>
<div><font size="-1"> a) is only one or the other will be
able to do what I want to do?<br>
</font></div>
<div><font size="-1"> b) if both are feasible which would
have the simpler implementation?</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1">The project involves writing an API that
will run in a multi-threaded application and is responsible
for serializing all access to a device structure. Therefore
the first thing in every function in the API must be to call
api_enter (which will among other things acquire a mutex on
the device) and the last thing before returning must be to
call api_exit. Also I want to enforce single exit point from
every API function - or certainly if there are any return
points that bypass the api_exit call.<br>
</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1">So here is an example function with errors
I want to catch highlighted.</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1">int api_foo(device_t *dev) {</font></div>
<div><font size="-1"> int ret_val = 0;<br>
</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1"> bar(); // fn calls & decls before
api_enter is ok- just don't access dev.</font></div>
<div><font size="-1"> dev->bla = 1; // NO! device access
before api_enter() called</font></div>
<div><font size="-1"> api_enter(dev); // error if this call
is not present exactly once</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1"> if (dev->bla)</font></div>
<div><font size="-1"> return; // NO! didn't call api_exit
before rtn. Also two return points</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1"> if (dev->ma) {</font></div>
<div><font size="-1"> ret_val = 1;<br>
</font></div>
<div><font size="-1"> goto cleanup;</font></div>
<div><font size="-1"> }</font></div>
<div><font size="-1"> tweak(dev);<br>
</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1">cleanup:</font></div>
<div><font size="-1"> api_exit(dev); // error if this is not
present exactly once<br>
</font></div>
<div><font size="-1"> dev->bla = 1; //NO! device access
after api_exit()<br>
</font></div>
<div><font size="-1"> return ret_val;<br>
</font></div>
<div><font size="-1">}</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1">I don't think it matters but the project is
C compiled with gcc.<br>
</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1">Also if both are feasible any other
pointers, tips or good resources would be appreciated. E.g
is there a totally different methodology I'm not considering
- e.g. would using something like pycparser be a lot easier
- though I'd prefer to keep it in clang as we plan to use
tidy & static analyzer in any case for standard QA.<br>
</font></div>
<div><font size="-1"><br>
</font></div>
<div><font size="-1">Thanks for reading,</font></div>
<div><font size="-1">Billy.<br>
</font></div>
</div>
<font size="-1">
</font><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
</body>
</html>