Usually, the logic that deals with graphics rendering passes (and their schedule, and when they're gonna run, etc) is handled by a separate thread. However that thread is already implemented (up and running) by the platform you use to develop your game loop (and game).
So in order to obtain a game loop where the game logic updates independently of the graphics refresh schedule you don't need to make extra threads, you just tap into the already existing thread for said graphics updates.
This depends on what platform you're using. For example:
if you're doing it in most Open GL related platforms (GLUT for C/C++, JOLG for Java, Android's OpenGL ES related Action) they will usually give you a method/function which is periodically called by the rendering thread, and which you can integrate into your game loop (without making the gameloop's iterations dependent on when that method is called). For GLUT using C, you do something like this:
glutDisplayFunc(myFunctionForGraphicsDrawing);
glutIdleFunc(myFunctionForUpdatingState);
in JavaScript, since there's no multi-threading (that you can reach programmaticaly)use Web Workers
since there's no multi-threading (that you can reach programmaticaly), you can also use the "requestAnimationFrame" mechanism to get notified when a new graphics rendering will be scheduled, and do your game state updates accordingly.
Basically what you want is a mixed step game loop: you have some code that updates the game state, and which is called inside the main thread of your game, and you also want to periodically tap into (or be called back by) the already existing graphics rendering thread for heads up as to when it's time to refresh the graphics.
