In general, no, not really, but you can probably get away with it in practice. The game makes no attempt to make this safe, or syncronize calls, but this usually doesn't matter for most reader methods, and many simple writer methods.
Functions usually use local variables on the stack, so there are no inherent reentry problems with most functions coming from the compiler or library. The main issue is how they interact with the global game state. (Which basically means watch out for all of them). Also, scr_snprintf might be something to be careful with. It likely calls standard C library functions which can be notorious for using statically allocated buffers which cause reentry problems (even in a single thread). Most of the Outpost 2 API functions don't seem to rely on any problem library calls though.
So basically the usual multithreading warnings apply concerning race conditions.
A. Watch out for update methods that require a read-modify-write cycle, such as updating a bit in a bitmask (such as to give a player a tech). These can have race conditions that may cause writes to appear to vanish. This type of probably usually doesn't cause the game to crash.
B. Watch out for update methods that update multiple values at once. A race condition may cause the values to be set to an inconsistent state. This can cause the game to crash, although if you're lucky it might not.
B1. Watch out for memory management functions, as the memory management variables would fall under this multiple update category. Watch out for functions that create units or triggers (or destroys them).
C. Watch out for functions that traverse complicated data structures which might change during traversal.
C1. Functions that iterate over units using their linked list pointers fall under this category. The links can be broken or rearranged at arbitrary times. The ordering of link updates and pointed to record updates is also not well defined. If a link in a unit list changes, you might miss processing a unit, or process the same unit twice. You might also have a null pointer issue if a test is performed against null (end of list) separately from the data load to process the next item. Such a race condition will cause the program to crash. This possiblity depends on the exact order of link updates though, so it may or may not be possible. A more likely outcome though might be to follow a pointer to a stale unit record which is no longer active.
