[cfe-dev] clang-tidy or static analyzer or ...

[Neil Nelson via cfe-dev]

An idea to avoid a mutex that may block the remaining threads.

This page shows std::atomic::operator++
http://www.cplusplus.com/reference/atomic/atomic/operatorplusplus/

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 *.

At this point there is no waiting for the multiple threads.

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.

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.

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.

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.

Neil Nelson

On 7/2/19 1:13 PM, Billy O'Mahony via cfe-dev wrote:
> Hello,
>
> 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.
>
> My questions are:
>     a) is only one or the other will be able to do what I want to do?
>     b) if both are feasible which would have the simpler implementation?
>
> 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.
>
> So here is an example function with errors I want to catch highlighted.
>
> int api_foo(device_t *dev) {
>     int ret_val = 0;
>
>     bar();  // fn calls & decls before api_enter is ok- just don't 
> access dev.
>     dev->bla = 1; // NO! device access before api_enter() called
>     api_enter(dev);   // error if this call is not present exactly once
>
>     if (dev->bla)
>         return; // NO! didn't call api_exit before rtn. Also two 
> return points
>
>     if (dev->ma) {
>         ret_val = 1;
>         goto cleanup;
>     }
>     tweak(dev);
>
> cleanup:
>     api_exit(dev); // error if this is not present exactly once
>     dev->bla = 1; //NO! device access after api_exit()
>     return ret_val;
> }
>
> I don't think it matters but the project is C compiled with gcc.
>
> 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.
>
> Thanks for reading,
> Billy.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190703/33d74c61/attachment.html>