I'm not writing to a single file, but to one different file per Thread.

There is no way to know that from the code snippet you posted. And if each thread is writing to a different file, why are you mutexing? lock($x); $fh->print("$record\n"); Even your choice of mutex name seems calculated to obscure your real purpose.

I'm not taking advantage of the CPU because I serialize the processing.

Even if you weren't serialising, you still won't gain anything by throwing threads at an IO-bound process unless you can overlap the IO. If, for example, you needed to communicate with several remote servers, then assuming sufficient bandwidth, you can reduce the overall program time by overlapping the IO to those servers. Using 1 thread per concurrent server is an effective means of doing that.

But, on the basis of your descriptions such as they are, and the code snippets you posted, removing the locking is unlikely to produce any substantial gain. The reason is that--unless your files are all on different drives--all your threads will be competing for throughput and latency of one disk drive.

Ie. Even if you remove your serialisation, your concurrent writes will be serialised by the disk drive itself. The read head can only be in one place at one time, and so you can only be writing to one file at one time.

There may be some small (tiny..you know, really, really small) gains as a result of filesystem write caching and DD-based write-extent re-ordering, but it's unlikely to be something you would be able to measure on a general purpose system with other concurrent activities. You'd have to use a laboratory conditions system to detect it. And those kind of gains are useless in real-world scenarios.

I've started a new node related to this issue.