On 16.09.2019 20:07, Leyne, Sean wrote:
Roman,
From: Roman Simakov <[email protected]>
Sent: Monday, September 16, 2019 7:51 AM
I guess it would be interesting alternative for spinlock
(https://kernelnewbies.org/Linux_5.3)
1.6. Power efficient userspace waiting with the umwait x86 instructions
More description is here:
https://lwn.net/Articles/790920/
It is a shame that:
- will only be available on new Intel Tremont micro-architecture CPUs, whenever
they ship
- will not be available for AMD CPUs, the new ROME/EPYC 2 CPUs are kicking
Intel's offering
- will not be available via Windows API for some time
I think it is worthy to create a JIRA ticket for this issue, but believe that
it should not be implemented until Windows API support is available at the very
least.
That's not completely true - we can provide OS-specific implementations
for various classes, particular for syncs we always do it - critical
section in windows and mutex in posix are 2 different things from API
calls POV. Cumrently we have:
class Spinlock : public Mutex
and nothing prevents to keep this current (IMHO not efficient) way for
windows in case of no API.
Need to detect CPU type on the fly and select one or other way to work
with spinlock may be a bit more problematic (we need to do it in
runtime) but must say I also do not see something tragic with it.
The articles don't mention what if applications would need to detect if umwait
is implemented/active, and implement alternate logic if not, or will OSs need
to have a default implementation for incompatible CPUs.
IMHO application - doing that in OS kills performance benefits of
umwait. May be C-runtime library may help us with it...
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
