Is there a way to introduce a variable which is defined in the main program and is seen from external modules.

Sure. See our.

What is a drawback of such a variable

There is extensive literature out there, for example search for why are global variables bad. In short: global state makes programs harder to understand, to debug, can cause problems with recursion and concurrency, and is often a sign of bad encapsulation.

In this example from perldoc will not $bar declared "our" in Foo conflict in package Bar with "use strict" ?

package Foo;
our $bar; # declares $Foo::bar for rest of lexical scope
$bar = 20;
..........................
#
package Bar;
use strict;
print $bar; # prints 20, as it refers to $Foo::bar
[download]

Why should it?

our $bar creates an entry in the current package, and a lexical alias to it. The lexical alias persists to the next package too, because packages and lexical scopes are completely orthogonal.

Perl 6 - links to (nearly) everything that is Perl 6.

What is a drawback of such a variable, say for multithreading,

If it is read-only. Ie. just conveying some piece of static information from the main program to the modules/threads, there is no significant problem.

If it is intended to act as a conduit for passing dynamic information back and forth between threads, then you would need to apply locking.

In general, there is no difference between obtaining a piece of static information from a global variable, and calling a (global) function (singleton instantiator) to obtain that information. Both involve the calling code "knowing" an well-known name.

Eg. $My::Config::DBhandle->somemethod( ... );

or My::Config->new()->get_DBHandle()->somemethod( ... );

You may use the "vars" module.

See: use vars;