Exactly. First of all it's interesting to understand an effect of implementation and then we can at least to keep it in mind.
вт, 17 сент. 2019 г. в 13:58, Alex Peshkoff via Firebird-devel <firebird-devel@lists.sourceforge.net>: > > On 16.09.2019 20:07, Leyne, Sean wrote: > > Roman, > > > >> From: Roman Simakov <roman.sima...@gmail.com> > >> 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 -- Roman Simakov Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
