By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,660 Members | 1,187 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,660 IT Pros & Developers. It's quick & easy.

calling functions at the same time

P: n/a
I need a script to call several functions at the same time. How does one
call more than one function simultaneously?

Jul 18 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
bart_nessux wrote:

I need a script to call several functions at the same time. How does one
call more than one function simultaneously?


You can call them pseudo-concurrently by starting a new thread for each
one. You cannot call them truly concurrently unless you have a separate
CPU for each function.

Mitchell Timin

--
"Many are stubborn in pursuit of the path they have chosen, few in
pursuit of the goal." - Friedrich Nietzsche

http://annevolve.sourceforge.net is what I'm into nowadays.
Humans may write to me at this address: zenguy at shaw dot ca
Jul 18 '05 #2

P: n/a
In article <c6**********@solaris.cc.vt.edu>,
bart_nessux <ba*********@hotmail.com> wrote:
I need a script to call several functions at the same time. How does one
call more than one function simultaneously?


This has several smart-alecky answers, including "you don't",
and "with co-routines". The best way you can help yourself is
to describe a concrete situation where your (Python?) script
has a need to call even two functions simultaneously. It turns
out "simultaneously" has a plethora of meanings, and you're the
only one in a position to get others to understand which you
have in mind.

It'll also help to know whether you mean "function" as specific
to the Python language, or more abstractly, as a unit of useful
accomplishment.
--

Cameron Laird <cl****@phaseit.net>
Business: http://www.Phaseit.net
Jul 18 '05 #3

P: n/a
Cameron Laird wrote:
In article <c6**********@solaris.cc.vt.edu>,
bart_nessux <ba*********@hotmail.com> wrote:
I need a script to call several functions at the same time. How does one
call more than one function simultaneously?

This has several smart-alecky answers, including "you don't",
and "with co-routines". The best way you can help yourself is
to describe a concrete situation where your (Python?) script
has a need to call even two functions simultaneously.


I need to ping 4 hosts at exactly the same time from the same machine (I
plan to timestamp the pings) to test and measure network conditions over
different routes to different hosts. Putting all the ping hosts in a list
and looping through it is not a fair or balanced way to do this because of
the time differences.
It turns
out "simultaneously" has a plethora of meanings, and you're the
only one in a position to get others to understand which you
have in mind.
I mean it to mean: at the *exact* same time... concurrently. Like runners
starting a race together.

It'll also help to know whether you mean "function" as specific
to the Python language, or more abstractly, as a unit of useful
accomplishment.


Specific to Python.
Jul 18 '05 #4

P: n/a

"Bart Nessux" <ba*********@hotmail.com> wrote in message
news:c6**********@solaris.cc.vt.edu...
I need to ping 4 hosts at exactly the same time from the same machine (I
plan to timestamp the pings) to test and measure network conditions over
different routes to different hosts. Putting all the ping hosts in a list
and looping through it is not a fair or balanced way to do this because of the time differences.


If you do 24 trials, one for each permutation, the result would be about as
fair and balanced as you can get.

Terry J. Reedy


Jul 18 '05 #5

P: n/a
bart_nessux wrote:
I need a script to call several functions at the same time. How does one
call more than one function simultaneously?

i just added my first thread to a wxpython program today. simple. in
fact my first threaded program of any kind.

as indicated, threads might help you. you didn't mention your platform
but probably it has real thread support. nevertheless, this might not
be for you if you are running in a Unix environment with a
multiprocessing (forking) program.

you launch your threads:

import thread

# create a lock you can use to block the threads until you are ready
mymutex = thread.allocate_lock()

def MyConcurrentFunction():
# important concurrent stuff
pass

def ThreadThing():
# thread will hang on 'acquire' until mutex is released
mymutex.acquire()
# release lock for the next thread
mymutex.release()
# now do your stuff
MyConcurrentFunction()

mymutex.acquire()
# launch your threads
thread.start_new_thread(ThreadThing, ())
thread.start_new_thread(ThreadThing, ())
thread.start_new_thread(ThreadThing, ())...
# your threads are all hung on the 'acquire' statement
# release the lock, unblocking the threads
mymutex.release()
# now all your threads are grabbing and releasing the mutex

# all done

I just made that whole thing up. But i think that's more or less how
you launch threads.

you have to consider that the thread may run as soon as you launch it.
each thread could complete your special function before the rest of the
threads get launched.

i think you address that problem by creating a mutex or semaphore that
each thread must acquire before it can proceed. That is, the thread
will block (hang) waiting for the mutex to become available. (think of
a mutex as an abstract lock resource). when all your threads are
launched, the main program can release the mutex(es), unblocking the
threads. The threads will unhang, and do your concurrent thing, more or
less concurrently.

Understand that concurrency is not guaranteed (as i understand it). the
OS controls which thread runs when, and it is not deterministic.

you could use an list of mutexes, to get an iota more concurrency.

all this i learned this very day from Programming Python, pg 104. so
take my advice with a shovel of salt.

but it sounds like the way to go to me.
Jul 18 '05 #6

P: n/a
In article <c6**********@solaris.cc.vt.edu>,
Bart Nessux <ba*********@hotmail.com> wrote:
Jul 18 '05 #7

P: n/a
In article <c6**********@solaris.cc.vt.edu>, Bart Nessux wrote:
I need to ping 4 hosts at exactly the same time from the same machine
That simply can't be done.
(I plan to timestamp the pings) to test and measure network
conditions over different routes to different hosts. Putting
all the ping hosts in a list and looping through it is not a
fair or balanced way to do this because of the time
differences.
Exactly how many packets do you think are allowed on the wire
at once with Ethernet??
I mean it to mean: at the *exact* same time... concurrently. Like runners
starting a race together.


Not physically possible unless you've got 4 cpus with, 4
separate PCI buses, 4 Ethernet boards on 4 different Ethernet
segments, and some very special HW/SW to keep things
synchronized.

--
Grant Edwards grante Yow! I'm ANN LANDERS!! I
at can SHOPLIFT!!
visi.com
Jul 18 '05 #8

P: n/a
sigh. i just read what you want to do.

my answer was so cool too.

you are doing network diagnostics. it is unlikely that a non-network guy
(you) can cobble together a few lines of script and develop much in the
way of detailed diagnostics.

much better to find someone who already knows networking and use the
great many highly sophisticated tools that are already available (and free).

good luck

Jul 18 '05 #9

P: n/a
Bart Nessux wrote:
Cameron Laird wrote:

In article <c6**********@solaris.cc.vt.edu>,
bart_nessux <ba*********@hotmail.com> wrote:
I need a script to call several functions at the same time. How does one
call more than one function simultaneously?


This has several smart-alecky answers, including "you don't",
and "with co-routines". The best way you can help yourself is
to describe a concrete situation where your (Python?) script
has a need to call even two functions simultaneously.

I need to ping 4 hosts at exactly the same time from the same machine (I
plan to timestamp the pings) to test and measure network conditions over
different routes to different hosts. Putting all the ping hosts in a list
and looping through it is not a fair or balanced way to do this because of
the time differences.

It turns
out "simultaneously" has a plethora of meanings, and you're the
only one in a position to get others to understand which you
have in mind.

I mean it to mean: at the *exact* same time... concurrently. Like runners
starting a race together.

It'll also help to know whether you mean "function" as specific
to the Python language, or more abstractly, as a unit of useful
accomplishment.

Specific to Python.

You can't get greater then 1ms accuracy when measuring a time on todays
machines, and that will be less when measuring time over a network...
calling 4 ping functions one after the other will complete in much less
then 1ms (assuming its asynchronous, or threaded). So, even if you could
manage to send 4 packets at *exactly* the same time, it would be no more
accurate.

not sure how your planning to ping the hosts... check out the asyncore
and threading modules.
Jul 18 '05 #10

P: n/a
In article <kNIkc.1367$U75.564@edtnps89>, Knio wrote:
You can't get greater then 1ms accuracy when measuring a time
on todays machines, and that will be less when measuring time
over a network...
Not sure what you mean by "todays machines", but on a
Pentium-class machine running Linux, you get approx 1us
resolution with calls to time.time():

import time
t = []
for i in range(10):
t.append(time.time())
print t

[1083429542.284164, 1083429542.2841799, 1083429542.2841859,
1083429542.2841921, 1083429542.284198, 1083429542.284204,
1083429542.284209, 1083429542.284215, 1083429542.2842209,
1083429542.2842269]

The Linux network stack also provides timestamps on the network
packets with at least 1us resolution.
calling 4 ping functions one after the other will complete in much less
then 1ms (assuming its asynchronous, or threaded). So, even if you could
manage to send 4 packets at *exactly* the same time,
People, Ethernet is a _serial_ protocol. It allows exactly one
packet to be transmitted at a time. There is no way to send
more than one packet at a time.
it would be no more accurate.


--
Grant Edwards grante Yow! As President I
at have to go vacuum my coin
visi.com collection!
Jul 18 '05 #11

P: n/a
Grant Edwards wrote:
In article <kNIkc.1367$U75.564@edtnps89>, Knio wrote:
You can't get greater then 1ms accuracy when measuring a time
on todays machines, and that will be less when measuring time
over a network...


Not sure what you mean by "todays machines", but on a
Pentium-class machine running Linux, you get approx 1us
resolution with calls to time.time():


Keep in mind the difference between "accuracy" and
"resolution" (or "precision").

I think Knio is probably right that, unless you are
running on a realtime OS, you won't be able to
guarantee anything better than 1ms accuracy, and
quite probably not even that.

-Peter
Jul 18 '05 #12

P: n/a
In article <r4********************@powergate.ca>, Peter Hansen wrote:
You can't get greater then 1ms accuracy when measuring a time
on todays machines, and that will be less when measuring time
over a network...
Not sure what you mean by "todays machines", but on a
Pentium-class machine running Linux, you get approx 1us
resolution with calls to time.time():


Keep in mind the difference between "accuracy" and
"resolution" (or "precision").


I do.

Not only do you get 1us resolution, you get packet timestamp
_accuracy_ to well under 1ms according to tests I've run
comparing packet timestamps against an oscilloscope trace.

Delta-T accuracy of calls to time() are accurate to 1us as
well. Absolute accuracy depends on how you set your system
clock. Running NTP with in-kernel FLL control of the system
tick will generally allow you to maintain absolute accuracies
of under 100us.
I think Knio is probably right that, unless you are running on
a realtime OS, you won't be able to guarantee anything better
than 1ms accuracy, and quite probably not even that.


Under Linux, I can guarantee you the answer you get back from
time.time() is accurate to 1us. However, it is a multitasking
system, and there are other things running. While it's easy to
_determine_ exactly when you called time.time(), it's difficult
to _control_ the point in time when you call time.time(). When
your task does get a chance to run, and you do get to call
time.time(), you'll generally get a result accurate to 1us.

If I do a busy-wait loop with nothing else running, I've been
able to accurately measure pulsewidths of a few microseconds
under Linux using the gettimeofday() call (which I believe is
what time.time() calls.

As soon as there are other ready tasks, the accuracy of the
measurement quickly deteriorates to tens of millisconds due to
scheduling latencies.

--
Grant Edwards grante Yow! It's today's SPECIAL!
at
visi.com
Jul 18 '05 #13

P: n/a
Grant Edwards wrote:
In article <r4********************@powergate.ca>, Peter Hansen wrote:

You can't get greater then 1ms accuracy when measuring a time
on todays machines, and that will be less when measuring time
over a network...

Not sure what you mean by "todays machines", but on a
Pentium-class machine running Linux, you get approx 1us
resolution with calls to time.time():


Keep in mind the difference between "accuracy" and
"resolution" (or "precision").

I do.

Not only do you get 1us resolution, you get packet timestamp
_accuracy_ to well under 1ms according to tests I've run
comparing packet timestamps against an oscilloscope trace.

Delta-T accuracy of calls to time() are accurate to 1us as
well. Absolute accuracy depends on how you set your system
clock. Running NTP with in-kernel FLL control of the system
tick will generally allow you to maintain absolute accuracies
of under 100us.

I think Knio is probably right that, unless you are running on
a realtime OS, you won't be able to guarantee anything better
than 1ms accuracy, and quite probably not even that.

Under Linux, I can guarantee you the answer you get back from
time.time() is accurate to 1us. However, it is a multitasking
system, and there are other things running. While it's easy to
_determine_ exactly when you called time.time(), it's difficult
to _control_ the point in time when you call time.time(). When
your task does get a chance to run, and you do get to call
time.time(), you'll generally get a result accurate to 1us.

If I do a busy-wait loop with nothing else running, I've been
able to accurately measure pulsewidths of a few microseconds
under Linux using the gettimeofday() call (which I believe is
what time.time() calls.

As soon as there are other ready tasks, the accuracy of the
measurement quickly deteriorates to tens of millisconds due to
scheduling latencies.


Thanks to all for the tips and advice. I experimented with threading...
it works, but I don't fully understand it so I'm not using it. I ended
up using ntp on 4 hosts (side by side on the network) to do the pings. I
wrote some socket server/client scripts so that all four hosts can start
pinging together. I understand this approach and it's working well.

Thanks again,
Bart

Jul 18 '05 #14

P: n/a

"Bart Nessux" <ba*********@hotmail.com> wrote in message
news:c6**********@solaris.cc.vt.edu...
Cameron Laird wrote:
In article <c6**********@solaris.cc.vt.edu>,
bart_nessux <ba*********@hotmail.com> wrote:
I need a script to call several functions at the same time. How does one
call more than one function simultaneously?

This has several smart-alecky answers, including "you don't",
and "with co-routines". The best way you can help yourself is
to describe a concrete situation where your (Python?) script
has a need to call even two functions simultaneously.


I need to ping 4 hosts at exactly the same time from the same machine (I
plan to timestamp the pings) to test and measure network conditions over
different routes to different hosts. Putting all the ping hosts in a list
and looping through it is not a fair or balanced way to do this because of
the time differences.

The network guy in me says that pinging 4 machines at the same time from 1
machine is not fair and
balanced. your network card really only does 1 request at a time... I would
think that the only fair judge
is to do it on 4 machines on the same segment, or 4 cards in the same
machine, otherwise you're bottleneck
becomes the single network card..
My opinion...
bobb

It turns
out "simultaneously" has a plethora of meanings, and you're the
only one in a position to get others to understand which you
have in mind.


I mean it to mean: at the *exact* same time... concurrently. Like runners
starting a race together.

It'll also help to know whether you mean "function" as specific
to the Python language, or more abstractly, as a unit of useful
accomplishment.


Specific to Python.

Jul 18 '05 #15

P: n/a
Grant Edwards wrote:
In article <r4********************@powergate.ca>, Peter Hansen wrote: (Someone else wrote this first part, then Grant's reply, then mine)
You can't get greater then 1ms accuracy when measuring a time
on todays machines, and that will be less when measuring time
over a network...

Not sure what you mean by "todays machines", but on a
Pentium-class machine running Linux, you get approx 1us
resolution with calls to time.time():


Keep in mind the difference between "accuracy" and
"resolution" (or "precision").


I do.

Not only do you get 1us resolution, you get packet timestamp
_accuracy_ to well under 1ms according to tests I've run
comparing packet timestamps against an oscilloscope trace.


[snip other technical details]
As soon as there are other ready tasks, the accuracy of the
measurement quickly deteriorates to tens of millisconds due to
scheduling latencies.


The last sentence is really the whole point. The OP needs
to be aware that the accuracy *cannot* be *guaranteed*
to better than "tens of milliseconds", overall, regardless
of the "accuracy" of the clock tick or the resolution of
anything...

The notes on timeit.py are helpful in this respect, however:
taking the shortest result of repeated measurements is a
pretty good way to get an "accurate" number, most of the
time. The other, higher results represent the interference
of all those other tasks which will tend to run as you
try to take measurements.

-Peter
Jul 18 '05 #16

P: n/a
Grant Edwards wrote:
In article <kNIkc.1367$U75.564@edtnps89>, Knio wrote:

You can't get greater then 1ms accuracy when measuring a time
on todays machines, and that will be less when measuring time
over a network...

Not sure what you mean by "todays machines", but on a
Pentium-class machine running Linux, you get approx 1us
resolution with calls to time.time():

[snip]


ah, interesting.. on my windows machine (pentium 4) I only have a 1ms
timer resolution.

import time
t = []
for i in range(10):
t.append(time.time())
print t

[1083451302.5739999, 1083451302.5739999, 1083451302.5739999,
1083451302.5739999, 1083451302.5739999, 1083451302.5739999,
1083451302.5739999, 1083451302.5739999, 1083451302.5739999,
1083451302.5739999]

Jul 18 '05 #17

P: n/a
Bart Nessux <ba*********@hotmail.com> writes:
I mean it to mean: at the *exact* same time... concurrently. Like runners
starting a race together.


On how many processors? You need to tell your operating system
services to schedule the two python funtion calls to each processor
simultaneously. I don't think anything in Python will let you do that.
Jul 18 '05 #18

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 2004-04-30T23:43:37Z, Bart Nessux <ba*********@hotmail.com> writes:
I need to ping 4 hosts at exactly the same time from the same machine (I
plan to timestamp the pings) to test and measure network conditions over
different routes to different hosts. Putting all the ping hosts in a list
and looping through it is not a fair or balanced way to do this because of
the time differences.


In other words, you want to emulate the functionality of fping without using
fping. Is that about right?
- --
Kirk Strauser
The Strauser Group
Open. Solutions. Simple.
http://www.strausergroup.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAlRaz5sRg+Y0CpvERAt8xAJ4sS+FzCv/Bm57o2b3s3Weh2yTV3gCeM68p
JVstKJijYWIQxU9+izWk7hQ=
=zCda
-----END PGP SIGNATURE-----
Jul 18 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.