Wine Developers Are Working On A New Linux Kernel Sync API To Succeed ESYNC/FSYNC

[oiaohm]

You are going to get a lot of objections if you try to turn the LINUX kernel into a Windows kernel directly. That's going to be a disaster.

A longer time ago I have taken a look at the esync source code, and it is doing the same kind of things that I am talking about. Except I am proposing other (existing) technologies instead of using eventfd.

Something to remember esync code does not work that games and other things needing windows behaviour does work. That was covered in the post asking for this functionality.

[indepe]

This is you being wrong. Wine is a Compatibility Layer. So wine tries to avoid emulation of the Windows kernel where ever possible, Its is required to avoid emulating Windows kernel where possible to avoid the performance over head.

Wine developers are wanting the compatible locking in the Linux kernel so it does not have to be emulated instead just straight up substituted.

Wine is not emulation is old name of Wine because instead of emulating windows kernel where possible its substitution with what the host OS kernel provides.

You are going to get a lot of objections if you try to turn the LINUX kernel into a Windows kernel directly. That's going to be a disaster.

A longer time ago I have taken a look at the esync source code, and it is doing the same kind of things that I am talking about. Except I am proposing other (existing) technologies instead of using eventfd.

[oiaohm]

When the locking happens inside the Windows kernel, it is still atomic locking, it just happens hidden by the Windows kernel, under the Windows kernel's control.

But in WINE the emulation of a Windows kernel call happens in Linux user space (except if that userspace function in turn calls the Linux kernel).

So you have 3 layers: 1) Windows application, 2) WINE emulation layer, 3) Linux kernel.
The WINE emulation layer is inside the Windows kernel (so to speak), but in LINUX user space.

So in this discussion when we talk about userspace, we mean the WINE layer which is inside the emulated Windows kernel.

That means you cannot use userspace atomic operations in the Windows application for events, but you can use LINUX userspace atomic operations in the WINE layer emulating the inside of the WIndows kernel.

This is you being wrong. Wine is a Compatibility Layer. So wine tries to avoid emulation of the Windows kernel where ever possible, Its is required to avoid emulating Windows kernel where possible to avoid the performance over head.

Wine developers are wanting the compatible locking in the Linux kernel so it does not have to be emulated instead just straight up substituted.

Wine is not emulation is old name of Wine because instead of emulating windows kernel where possible its substitution with what the host OS kernel provides.

[oiaohm]

Events are absolutely atomic on Windows. Obviously all events have a state else they wouldn't be events (you'd only have PulseEvent). Actually all synchronization objects have state. And yes you absolutely can modify this state atomically, especially with the kernel syscalls (which is what it is under Windows). EVENT_MODIFY_STATE is just an access right, it has nothing to do with atomic or not, just "permissions".

just "permissions".< This is the big catch permissions have to be processed somewhere this is what you are missing. Pre atomic cpu instructions perform permission checks on locking functions is acceptable behaviour. Post cpu atomic instruction designs avoid this as it brings a overhead.

ResetEvent is a basic function that simply sets the state of an event to non-signaled. It's absolutely atomic. To be fair, you can do it even in userspace atomically, by using the "xchg" instruction, which would ALSO give you the event's former state, atomically. It might be implemented that way, who knows?

The stuff design pre atomic instructions in cpu use syscall to kernel space for the atomic operations. These are not done by the xchg instruction in userspace. There are kernel space. ResetEvent and PulseEvent in the syscall are checking if you still have the permission to perform them in Windows.

Weasel they design is before the xchg instruction existed because the code starts on alpha not x86 in Event area. xchg is a more modern instruction than that section of the Windows code base.

Regardless, the whole point of any synchronization API is to synchronize things, and being atomic is a hard requirement. Otherwise, the API is deeply flawed (like PulseEvent is).

PulseEvent flawed logic is part of wait multi objects under windows. Yes the Event based locking under windows is hell for the oddities it allows with a lot of odd ball quirks and its used all over the place in Win32 api.

Yes the whole point of any synchronisation API should be to synchronise things but this is windows we are talking about with its Event system and other old synchronise API/ABI they are broken in places applications are designed to function with the way the windows synchronise systems fail to-do what you expect.

[indepe]

Your general atomic locking is not your old school privilege/kernel controlled/pre atomic locking. The big things here is the old pre atomic locking include methods to take back the lock by force that requires extra information on who has the lock to be tracked by privilege party being the kernel. Yes I know its a idea to say we will avoid syscalls to take out a lock but these old pre atomic are designed to use syscalls and the difference in privilege between kernel and user-mode and have security privileges on the locking to be processed as part of the locking solution. These beasts are different.

Yes saying this stuff can be implemented with atomic locking in userspace means you don't understand the problem at all. These are locking structures with privileges designed to be kernel processed that were not designed to use atomic to avoid syscalls. Attempting to avoid syscall makes implementing them hell.

When the locking happens inside the Windows kernel, it is still atomic locking, it just happens hidden by the Windows kernel, under the Windows kernel's control.

But in WINE the emulation of a Windows kernel call happens in Linux user space (except if that userspace function in turn calls the Linux kernel).

So you have 3 layers: 1) Windows application, 2) WINE emulation layer, 3) Linux kernel.
The WINE emulation layer is inside the Windows kernel (so to speak), but in LINUX user space.

So in this discussion when we talk about userspace, we mean the WINE layer which is inside the emulated Windows kernel.

That means you cannot use userspace atomic operations in the Windows application for events, but you can use LINUX userspace atomic operations in the WINE layer emulating the inside of the WIndows kernel.

Hope that helps.

[Weasel]

I really should not have to be doing this you are meant to be a Windows programmer apparently you don't know your stuff.

https://docs.microsoft.com/en-us/win...ltiple-objects

Notice here wait for multiple is not Mutex but instead event. Happens that the event in windows is not atomic design.

https://docs.microsoft.com/en-us/win...-access-rights

The give away is right on this page. EVENT_MODIFY_STATE is the give away. The fact state is meant to be able to change while running.

Events are absolutely atomic on Windows. Obviously all events have a state else they wouldn't be events (you'd only have PulseEvent). Actually all synchronization objects have state. And yes you absolutely can modify this state atomically, especially with the kernel syscalls (which is what it is under Windows). EVENT_MODIFY_STATE is just an access right, it has nothing to do with atomic or not, just "permissions".

ResetEvent is a basic function that simply sets the state of an event to non-signaled. It's absolutely atomic. To be fair, you can do it even in userspace atomically, by using the "xchg" instruction, which would ALSO give you the event's former state, atomically. It might be implemented that way, who knows?

Regardless, the whole point of any synchronization API is to synchronize things, and being atomic is a hard requirement. Otherwise, the API is deeply flawed (like PulseEvent is).

[oiaohm]

WTF is a pre atomic method? Give actual examples.

I really should not have to be doing this you are meant to be a Windows programmer apparently you don't know your stuff.

https://docs.microsoft.com/en-us/windows/win32/sync/waiting-for-multiple-objects

Notice here wait for multiple is not Mutex but instead event. Happens that the event in windows is not atomic design.

https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-object-security-and-access-rights

The give away is right on this page. EVENT_MODIFY_STATE is the give away. The fact state is meant to be able to change while running.

Modify state access, which is required for the SetEvent, ResetEvent and PulseEvent functions.

I do like now that the ResetEvent goes to 404. If you cannot work out these pre atomic lock designs can in places be here be dragons. Reset event the wrong way of course is going to result in the data protection you thought the event was going to give you not being there as well.

Do notice on this page that Mutex there is a space left in the API/ABI for a Mutex to be a muggable lock like a EVENT is with the but that does not mean its not muggable.

There is also another bit of fun on the security page.

SYNCHRONIZE (0x00100000L) The right to use the object for synchronization. This enables a thread to wait until the object is in the signaled state.

Notice if you can wait on any of the windows built in locking structures you have to have a privilege. Do note its legal to change a thread from being allowed with SYNCHRONIZE to not allowed while its holding the lock be it Windows kernel controlled Mutex so is meant to result in the lock being reclaimed from the process by kill it for perform a now unprivileged action.

Your general atomic locking is not your old school privilege/kernel controlled/pre atomic locking. The big things here is the old pre atomic locking include methods to take back the lock by force that requires extra information on who has the lock to be tracked by privilege party being the kernel. Yes I know its a idea to say we will avoid syscalls to take out a lock but these old pre atomic are designed to use syscalls and the difference in privilege between kernel and user-mode and have security privileges on the locking to be processed as part of the locking solution. These beasts are different.

Yes saying this stuff can be implemented with atomic locking in userspace means you don't understand the problem at all. These are locking structures with privileges designed to be kernel processed that were not designed to use atomic to avoid syscalls. Attempting to avoid syscall makes implementing them hell.

[indepe]

Ok, I understand what you're trying to say now. You want to implement the whole thing in userspace, just with locks to protect the code from races.

Sounds about right!

Tbh, it sounds pretty nice in practice, but I'm guessing this approach suffers from contention or some other thing they measured. I don't know—they seem to be specifically looking for "kernel options". BTW esync currently emulates some of these things pretty badly, not just in terms of performance, but having race conditions. That's why some weird games don't even work with esync on.

For an efficient implementation, I think it will be most important to recycle any dynamic memory, instead of de-allocating and re-allocating it, and to do even that and everything else outside the locked sections as much as possible. (And perhaps in other specific places use lockfree atomics whenever possible.)

Anyway you gave me some ideas to try for my "lockless" (as in, syscalls, not atomic locks) design of an app I have.

Yep....

[Weasel]

So maybe PulseEvent poses special problems that are hidden from plain view. For example, why do you think there need to be 2 syscalls unless the whole thing is a single syscall?

In the absence of knowing about any Windows specifics, I would think of something like:

{
acquire_lock_of_event(e);
thread t = thread_waiting_for_event(e);
clear_waitlist_of_event(e);
reset_event(e);
release_lock_of_event(e);
if (t != NULL) {
wake_thread( t );
}
}

Only wake_thread would invoke a syscall, and only if there is actually a thread waiting.
(EDIT: This is of course a simplification. For example instead of the "thread t", it would be something like "wait_entry_for_thread".)
(EDIT 2: Note that the potential syscall in wake_thread is outside the lock.)

Ok, I understand what you're trying to say now. You want to implement the whole thing in userspace, just with locks to protect the code from races.

Tbh, it sounds pretty nice in practice, but I'm guessing this approach suffers from contention or some other thing they measured. I don't know—they seem to be specifically looking for "kernel options". BTW esync currently emulates some of these things pretty badly, not just in terms of performance, but having race conditions. That's why some weird games don't even work with esync on.

Anyway you gave me some ideas to try for my "lockless" (as in, syscalls, not atomic locks) design of an app I have.

[Weasel]

No that would not work. Because you have pre atomic methods and other code in modern day windows applications that are atomic methods. Anyone porting code to DEC Alpha back in Windows 4.0 days use to run into that problem as well where you code areas that were using atomic methods that was fine on i386 x86 or better was now totally screwed.

Pre atomic methods for doing locking can be used on a CPU that support atomic methods but atomic methods cannot be used to replace them in all cases.

WTF is a pre atomic method? Give actual examples.