Could you go ahead and elaborate a little bit on the alternative you have in mind, anyway?

Assuming this is addressed to me rather than the OP...

It is hard to say much more than I already did in my post above without a much clearer picture of what the OP's code does. The first thing I'd need is a description of why the OP is using threading? What benefits is s/he hoping to derive from their use? Is this an attempt to gain performance through the parallelisation of CPU-intensive code? Or allowing one part of the program to continue whilst another waits on IO?

I used threads to gain performance by allowing one part of the program to continue while another waits on IO.

Sorry. But I'll need more than that to go on. A description of the basic structure of the application at least.

For example, what would the methods that you wish to call from the 'other' threads do to the state of the object? How does that relate to what that other thread is doing? etc.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

Note that you don't need to use threads to do that. You can use assynchronous IO. Take a look at POE, AnyEvent and IO::Async.

daniel

/me nods...   If you do intend to do it that way, a few pointers I would suggest to thee:

• Let the thread that is doing I/O retrieve what it may retrieve and then place a frozen copy of the data onto a queue for further consumption.   It is unwise to try to be “efficient” about placing it into some shared buffer since this creates serious timing dependencies – and, likely as not, destroys the actual benefit of threading.
• Let there only be enough copies of the I/O thread to reasonably accommodate what I/O the computer can actually, reasonably do; and then, let those threads stick-around forever.   Build a queue for all of them to listen-to and another queue for all of them to post results back to.   If requests briefly “pile up” in those queues, then ... “So what.   That’s what queues are for.”   Such an arrangement is easily tunable and self-regulating.
• “Asynchronous I/O?”   Hmmmm, Might be useful, but might be more of a PITA than it pragmatically is worth, given that you’ve got a dedicated thread doing the I/O’s anyway.   Be mindful of how many requests might be up-in-the-air at any one moment, and of exactly what your hardware can reasonably be expected to do.   I/O requests usually don’t play well with others.   If a bunch of them are standing around, the room they’re standing around in gets awfully small, awfully quick.