There is some overhead for locking and unlocking a mutex. There is additional overhead for read/write locks because (typically) both a mutex and a semaphore must be locked and unlocked. However our experience so far is that this overhead is not very large compared to the cost of rendering.
However if the goal is (or might be) to use the node in an application where multiple threads are traversing the scene graph simultaneously, then the most important performance issue is to avoid having one thread block other threads. This essentially forces parallel execution back to sequential execution. For example, if the node’s glRender() method (like the one above) is protected by a class mutex such that only one thread can execute the method at a time, then this method may be a “bottleneck” that reduces overall performance. While one thread is executing this method, any other thread trying to traverse the node will be blocked, making it idle and not doing anything useful. Worse, if the method is protected by the class mutex and there are multiple instances of the node in the scene graph, then any thread traversing any instance of the node will block other threads trying to traverse any other instance of the node. This will further reduce performance.