I really want to look for a good way to lock the stdout,

Not at all. You don't need to lock STDOUT, whatever that means. What you really really want is mutual exclusion. That can be done by obtaining a lock, but it can be a lock on anything, as long as all the parties lock the same thing.

Since you're using threads, you can use a shared variable.

my $stdout_mutex :shared;

{
   lock($stdout_mutex);
   print ...;
}
[download]

Then again, if you're using threads, why are you using STDOUT at all. Why not use something like Thread::Queue instead?

Somewhat easier than using lock() all over your code, is to wrap print in your own sub that does that for you:

use threads;
use threads::shared;

my $sem :shared;
sub tprint {
    my $tid = threads->tid;
    lock $sem;
    print "$tid: ",@_, "\n";
}

sub twarn {
    my $tid = threads->tid;
    lock $sem;
    warn "$tid: ", @_;
}
[download]

Consider re-designing the script.   You don’t need n separate threads to check the health of n servers.   If already-developed open source tools like nagios cannot already do the job you’re building a solution for, then all you really need is (most likely...) one process that uses x socket(s) to send queries to y servers at least once every z seconds.   A simple select-based strategy will multiplex the incoming responses.

Assuming that you do not simply discover that Nagios is already able to do what you want, without you actually having to write anything new, the actual design of the program that you write will become so trivial that I suspect it will not actually require multithreading at all.

#!/usr/bin/perl

use strict;
use warnings;

select STDOUT;
$| = 1;
[download]

Flushes aren't guaranteed to be atomic, so that's not guaranteed to work even if you using a single single print per message and the messages don't exceed 4k in size.

-Greg