It would probably be a good idea to look at the templates and example projects. Guided by them, try to make a few simple games, like Minesweeper with a series of cubes that change color. Then, try to make a simple multiplayer title.
Also, with all of the macros and simplifications that Epic adds to their API, it actually feels a lot like developing in Java or C#. The engine has quite a few events (virtual functions in C++) that you can override to steal execution for a short period of time. Those are the brief windows where you do your work, returning execution back to UE4. Good examples are BeginPlay(), which is when a player is spawned into the world, Tick(float DeltaTime), which occurs once per frame for each object, and SetupInputComponent(), which is where Player Controllers bind action commands to C++ functions. You can then bind these action command strings, which you added in your SetupInputComponent() override, to actual buttons, axes, or gestures using the editor’s Input panel.
UE4 even has a framework for Remote Procedure Calls (RPCs). It allows you to call a function with some set of parameters on one machine, which causes it to execute on another machine, depending on the RPC type and where it’s called from. A “Server” RPC, when called from the client, runs on the server’s copy of that same object. A “Client” RPC, when called from the server, runs on the client’s copy of that same object. A “Multicast” RPC, when called from the server, runs on all copies of that same object, including the server and all connected clients.
So, to make a chat client, I would add a Server RPC subclass of PlayerController, and a Multicast RPC to my subclass of GameState. The Server RPC would have an FText parameter, containing the message string. Inside the method, it would validate that the message is okay (profanity filters, valid characters, etc.) and, if it is, call MyGameState->MulticastMyChatFunction() with the FText as a parameter. The body of this function would do what’s necessary to paint it on screen, log it, and/or whatever it needs to do.
So… again… check out the examples and get an idea for how UE4 does things. You will be very abstracted from the concepts of locking while(true) loops and thread sleeps… and probably with much better performance, too.
I whole-heartedly disagree with jwatte telling you to learn things first, though. One of the best ways to learn is by having a project that motivates you past your struggles. The risk of learning theory before applying it is that you’ll get bored and stop caring (especially since theory without application isn’t processed as easily by the brain – no context). As I said earlier, start with some simple projects, guided by the examples. (I was a high school science teacher for a little bit.)