I don't understand how you managed to have a long career being so thick.
The NT kernel is thread-safe. I take you have the same definition of "thread safety" as I do (and honestly, basically the whole industry has), as in, a piece of code or a system being used at the same time by multiple threads without causing errors, unexpected behaviour, or data corruption.
Windows offers, in its kernel:
Spinlocks, mutexes, semaphores, rwlocks, atomic increment/decrement/exchange etc, IRQL, supports kernel preemption, supports reference counting for kernel objects to manage object lifetimes, DPCs, SEH, has their own scheduler...
All of this means that it IS thread safe, those are a lot of tools to guarantee it, and most of those are very similar to what Linux offers in terms of safety. Of course without being able to see how it is implemented under the hood, but regardless, they work.
Not to mention, IIRC fork() is NOT thread-safe, you have to synchronize your shit yourself when using it...
What do you even mean with "a thread safe pointer to the kernel"? I've never heard of anything like it...
Maybe you mean something with shared memory? in which case I think you'd be more interested in pthreads rather than fork(), or even clone() if you want to go lower - NOT fork().
I already told you once and will tell you again: R's IMPLEMENTATION IS R's PROBLEM, NOT WINDOWS'
Personally I don't even believe you read or tried using future:: parallelly for that video you showed. That could be anything.
But then again, since many other languages and millions of other programs offer multi-threading on windows without issues, even if parallelly is not a solution - R's implementation and Parallelly's implementation are NOT sufficient to say that windows itself isn't multithreaded...
it can... with windows.h you just call CreateThread and pass whatever you want, windows will do the rest and take care of you (you can HANDLE whatever you like as well, there are what, hundreds of functions you can just call from kernel32.dll and get windows to do whatever you want with it? don't take it from me, just click on the left column titled "synchronization reference" and then "synchronization functions" in this page)
This link should make you better informed...
Originally posted by mSparks
View Post
Windows offers, in its kernel:
Spinlocks, mutexes, semaphores, rwlocks, atomic increment/decrement/exchange etc, IRQL, supports kernel preemption, supports reference counting for kernel objects to manage object lifetimes, DPCs, SEH, has their own scheduler...
All of this means that it IS thread safe, those are a lot of tools to guarantee it, and most of those are very similar to what Linux offers in terms of safety. Of course without being able to see how it is implemented under the hood, but regardless, they work.
Not to mention, IIRC fork() is NOT thread-safe, you have to synchronize your shit yourself when using it...
Originally posted by mSparks
View Post
Maybe you mean something with shared memory? in which case I think you'd be more interested in pthreads rather than fork(), or even clone() if you want to go lower - NOT fork().
Originally posted by mSparks
View Post
Personally I don't even believe you read or tried using future:: parallelly for that video you showed. That could be anything.
But then again, since many other languages and millions of other programs offer multi-threading on windows without issues, even if parallelly is not a solution - R's implementation and Parallelly's implementation are NOT sufficient to say that windows itself isn't multithreaded...
Originally posted by mSparks
View Post
This link should make you better informed...
Comment