However, this means that I cant have a "global" db connection?

Correct. But this is not a restriction of Perl, or Perl's threads. The restriction lies within the DB vendor's libraries.

It's fundemental design requirement with threaded architectures, that APIs should be reentrant, but code that has been ported to threads from a pre-threaded environment frequently takes shortcuts to avoid too much change to legacy code. Often pre-threaded APIs simply do not lend themselves to reentrancy.

The classic example of this is the C function strtok(), which modifies it's argument, retains a library allocated pointer to the next argument, and forgets what delimiter it is using between successive calls. Long deprecated, but still a part of most C-libraries, it was never safe to use, but still is. There are many more hidden gotchas like it.

Guess the solution is to have the db obj in the dbUpdate function ONLY ...

The biggest problem with your design as posted is that you show no indication of how you are going to indicate to the db thread when the other thread is finished modifying the shared variables.

Ie. Even when you move $dbh = DBI->connect( ... ) inside the db thread, you still have to think about the fact that you do not control when your threads run, or when they get interupted.

I appreciate that you are only posting snippets to give a flavour of what you are doing and that you may well have thought about much more than you are showing, but while(1){ is an endless loop that does not bode well. If you have a high level pseudo-code description of your application, or even a wordful description of what you hope to achieve by using threads, it would be easier to advise you.