I have searched in google and found that there is no official document about this and some articles state that we can not create/modify/delete UObjects from other threads[See wiki.unrealengine.com]. However, I try to modify UObject in FRunnable thread and it seems to work fine. And I found that somebody have tried the same thing before and post a question at here[Modifying UObjects in FRunnable threads - Programming & Scripting - Unreal Engine Forums]. I read the answer and found that it is healful but not clear enough. And I really want to get more imformation about this. Thank you.
It works fine, until it doesn’t work fine, and then you’re busting out the debugger, and wondering what went wrong, and how exactly does MyObjPointer become null inbetween two lines of code, one of which just checked that it wasn’t nullptr?!
or worse, you’re not getting a crash so it’s difficult to track down, but you discover that your whatever you’re doing on the other thread is operating with data that is out of date.
Thanks for replying. I wanna know that what if I add lock in Run method of my Runnable, like the code below
static FCriticalSection Mutex;
FScopeLock* ScopeLock = new FScopeLock(&Mutex);
... //Modify UObject data using pointer to it
delete ScopeLock;
Now,is this a write method to modify UObject in Non-GameThread? I try this and it also works fine. I try to modify UObjetc data directly becase the data in the UObject is to large to copy. If I copy the data from GameThread to FRunnable, my computer will crash since menmory is not enough(my computer has 64GB memory)…So can you give me some advice? Somebody tell me that I can do the calculcation in the FRunnable thread and write data to a file, and GameThread can read data form the file after FRunnable thread finish calculating. I think this maybe a way to achive my goal, but this may not be a good way?
A mutex only helps if all threads lock it before accessing the shared object.
If you merely add a mutex and only your thread locks it, it doesn’t do anything to prevent other threads from changing the UObject while you’re accessing it. You’d have to modify the engine code so the mutex is locked whereever the engine accesses the UObject, too.
(also, don’t use FScopeLock with ‘new’, that kills its whole purpose, namely automatically unlocking the mutex when it goes out of scope 
)
There are probably some safe scenarios for safe multithreading (maybe look at the path finding or async level loading code).
What’s usually done is to extract the data needed for a thread to work into vanilla C++ types and communicate with the thread via a set of variables, with a mutex that both the worker thread and the main thread will hold a lock on while accessing.
I could give better advice if I knew on a higher level what you were trying to achieve. While I’m not great with multi-threaded code, the problems that I listed are problems that I’ve encountered in a game where other people have implemented some multi-threaded things that have done things in a less-than-safe fashion.
Thanks for your advice!
Thanks for replying. Actually I am implementing a method which can generate a large grid and the data of the grid is stored in a UObject using TArray. Also, this method will just run in Editor mode. Please tell me if you have any idea. Thanks in advance.