Home > Archive > PERL Beginners > June 2007 > Inter-thread communications
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Inter-thread communications
|
|
| Bob McConnell 2007-06-19, 3:59 am |
| This is an offshoot of the thread "Having trouble porting an application
to MS-Windows". This time I am looking at using fork() to separate input
and output handling. But I am not sure how some of the IPC handling
works in the Win32 environment.
I am trying to emulate the behavior of an existing POS system currently
installed at a client location without having to install and set up a
copy of that system. I want to create two threads, one to read data from
a serial port and one to write data to that same serial port. The data
in both cases is a framed packet with checksum and ACK/NAK responses.
This will have the affect of enabling full-duplex operations on the
serial port, where my previous version was, in effect, two-way
alternating half duplex. The framing is done with ASCII characters, like
so:
<SOH>header<STX>content<ETX>checksum<EOT>
1. The read thread must input the packet, validate the checksum and send
ACK/NAK out the port, via the write thread. The content is then stored
or sent on. It must also forward any ACK or NAK received to the transmit
thread. There is no chance of an ACK or NAK embedded in the packet, so
escapes are not necessary.
2. The write thread must frame the packet, insert the checksum, and
transmit it. Then it must wait up to three seconds for an ACK or NAK. If
it receives the ACK, it waits for another message. If it gets a NAK, or
times out, it transmits the packet again, up to three times. After three
tries, an error is recorded and it looks for another message. It also
must insert the ACK/NAK from the receive thread into the transmit data
stream, although that can be held until after the current packet has
been sent.
I have two questions about this. First, is there a standard Perl IPC
interface between threads? I am not familiar with pipes in this context,
although I have used mailboxes and single word messages in various
multi-processing environments, including POSIX threads.
Second, is there a way to set this up so the transmit thread timeout can
be easily implemented as a side effect of waiting for the ACK/NAK to
arrive on that interface? I was thinking of using a semaphore, but they
don't appear to be implemented on Win32.
For this emulation, the outgoing messages are read from a text file and
the incoming messages are stored in another text file. Timing of
outgoing messages is controlled when that file is read. I am hoping this
can provide a workaround for the alarm failure I ran into on the single
threaded version as well as being a better emulation of the actual
system.
Thank you,
Bob McConnell
Principal Communications Programmer
The CBORD Group, Inc.
61 Brown Road
Ithaca NY, 14850
Phone 607 257-2410
FAX 607 257-1902
Email rvm@cbord.com
Web www.cbord.com
| |
| Zentara 2007-06-19, 6:59 pm |
| On Mon, 18 Jun 2007 12:58:31 -0400, rvm@CBORD.com ("Bob McConnell")
wrote:
>I have two questions about this. First, is there a standard Perl IPC
>interface between threads? I am not familiar with pipes in this context,
>although I have used mailboxes and single word messages in various
>multi-processing environments, including POSIX threads.
This is a big topic, so I'll briefly try to bring you up to speed.
I'm assuming you are talking about threads in the pure sense, as opposed
to calling separate processes "threads". ( It's further  by
MSWindows, emulating fork with threads).
There are totally independent processes, for which you can do IPC with
pipes, sockets, shared memory segments, etc.
Threads are different.
Threads are sort of concurrent code which can all run under the same
parent pid. If one thread exits, the whole thread system will die. So
care must be taken. However, you can easily share scalar data between
running threads, and this is their advantage.
So the standard Perl IPC interface for threads, is shared variables:
see "perldoc threads::shared". Also to be
happy with threads under Perl, you need a version greater than 5.8
Perl5.6 uses an obsolete thread version which will give you trouble.
If you are not specifically interested in perl threads, you may want to
read "perldoc perlipc". The things mentioned in perlipc, are the
original methods of ipc, before threads came along (only recently).
There are 2 things threads can do for you.
1. Share variables in realtime between threads.
2. Share filehandles between threads, by passing their fileno
thru the shared variable mechanism.
The problem is that one thread will not know if another thread has
changed a shared variable, so you either need an event-loop system,
or a complex while() loop to constantly monitor the values of the shared
variables.
The typical setup is a main thread which has an event loop (Tk, POE,
Glib, etc), and as many worker threads as you want. The worker threads
will do things and set shared variables, and the main thread will
monitor the value of the shared vars and do what is needed.
The main thread will also clean up the worker threads at program end.
>
>Second, is there a way to set this up so the transmit thread timeout can
>be easily implemented as a side effect of waiting for the ACK/NAK to
>arrive on that interface? I was thinking of using a semaphore, but they
>don't appear to be implemented on Win32.
Yeah, it depends on how your code is written, but you can setup many
timers in an event-loop system to time out something. Warning.... alarm
does not work well in threads, you need timers.
See how GLib can help
http://perlmonks.org?node_id=538341
Also there is POE, and (Tk and Gtk2 if you want a GUI).
>
>For this emulation, the outgoing messages are read from a text file and
>the incoming messages are stored in another text file. Timing of
>outgoing messages is controlled when that file is read. I am hoping this
>can provide a workaround for the alarm failure I ran into on the single
>threaded version as well as being a better emulation of the actual
>system.
I run linux, so there may be win32 problems that I'm unfamiliar with,
but all of it seems feasible.
It seems that once the serial port connection is established, and you
have the filehandle, you could have a main thread to control, and 2
worker threads, one to send, and one to receive. You would setup
some shared variables, like "$ack_received" , etc., and share the fileno
of the port filehandle between the threads.
Then again, with a proper IO::Select setup, you may not need threads
at all.
You might want to ask this on http://perlmonks.org
A few monks there are good with win32, and Win32::SerialPort.
If you could show some pseudo-code it would be helpful to them.
Goodluck,
zentara
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
| |
| Bob McConnell 2007-06-19, 6:59 pm |
| > -----Original Message-----
> From: Linux@lists.develooper.com=20
> [mailto:Linux@lists.develooper.com] On Behalf Of zentara
> Sent: Tuesday, June 19, 2007 2:55 PM
> To: beginners@perl.org
> Subject: Re: Inter-thread communications
>=20
> On Mon, 18 Jun 2007 12:58:31 -0400, rvm@CBORD.com ("Bob McConnell")
> wrote:
>=20
> this context,
>=20
> This is a big topic, so I'll briefly try to bring you up to speed.
>=20
> I'm assuming you are talking about threads in the pure sense,=20
> as opposed
> to calling separate processes "threads". ( It's further by
> MSWindows, emulating fork with threads).
>=20
> There are totally independent processes, for which you can do IPC with
> pipes, sockets, shared memory segments, etc.
>=20
> Threads are different.
> Threads are sort of concurrent code which can all run under the same
> parent pid. If one thread exits, the whole thread system will die. So
> care must be taken. However, you can easily share scalar data between
> running threads, and this is their advantage.
>=20
> So the standard Perl IPC interface for threads, is shared variables:
> see "perldoc threads::shared". Also to be
> happy with threads under Perl, you need a version greater than 5.8
> Perl5.6 uses an obsolete thread version which will give you trouble.
>=20
> If you are not specifically interested in perl threads, you=20
> may want to
> read "perldoc perlipc". The things mentioned in perlipc, are the
> original methods of ipc, before threads came along (only recently).=20
>=20
> There are 2 things threads can do for you.
> 1. Share variables in realtime between threads.
> 2. Share filehandles between threads, by passing their fileno
> thru the shared variable mechanism.
>=20
> The problem is that one thread will not know if another thread has
> changed a shared variable, so you either need an event-loop system,
> or a complex while() loop to constantly monitor the values of=20
> the shared
> variables.
>=20
> The typical setup is a main thread which has an event loop (Tk, POE,
> Glib, etc), and as many worker threads as you want. The worker threads
> will do things and set shared variables, and the main thread will
> monitor the value of the shared vars and do what is needed.
>=20
> The main thread will also clean up the worker threads at program end.
>=20
> timeout can
> semaphore, but they
>=20
> Yeah, it depends on how your code is written, but you can setup many
> timers in an event-loop system to time out something.=20
> Warning.... alarm=20
> does not work well in threads, you need timers.
>=20
> See how GLib can help
> http://perlmonks.org?node_id=3D538341
>=20
> Also there is POE, and (Tk and Gtk2 if you want a GUI).
>=20
> text file and
> hoping this
> the single
>=20
>=20
> I run linux, so there may be win32 problems that I'm unfamiliar with,
> but all of it seems feasible.
>=20
> It seems that once the serial port connection is established, and you
> have the filehandle, you could have a main thread to control, and 2=20
> worker threads, one to send, and one to receive. You would setup
> some shared variables, like "$ack_received" , etc., and share=20
> the fileno
> of the port filehandle between the threads.
> Then again, with a proper IO::Select setup, you may not need threads
> at all.
>=20
> You might want to ask this on http://perlmonks.org
> A few monks there are good with win32, and Win32::SerialPort.
> If you could show some pseudo-code it would be helpful to them.
>=20
> Goodluck,
> zentara
I have been trying to implement this in ActivePerl 5.8.8.820 on W2K, so
I am working in the thread based fork() implementation. IPC does not
seem to exist in that implementation.
I had pretty much figured out that alarm doesn't work in Win32. I had
tried to use it to interrupt read() on a serial port, and that wasn't
working. Neither did SIGINT or SIGTERM. The only way to get out of it
was Ctrl->Break, which shuts down the whole process.
Unless the Glib timer can interrupt a serial port read() call, I don't
see any way to timeout a serial port input function on Win32.
Unfortunately, that means I will probably need to steal one of the FC5
boxes from the next room in order to get it to work.
Thank you,
Bob McConnell
| |
|
|
| Zentara 2007-06-20, 7:59 am |
| On Tue, 19 Jun 2007 15:44:18 -0400, rvm@CBORD.com ("Bob McConnell")
wrote:
>I have been trying to implement this in ActivePerl 5.8.8.820 on W2K, so
>I am working in the thread based fork() implementation. IPC does not
>seem to exist in that implementation.
For forked processes, you need pipes, sockets, or shared mem for
IPC.
You probably are better off sticking with threads on Win32, since
it only uses threads underneath it all.
>I had pretty much figured out that alarm doesn't work in Win32. I had
Alarm dosn't work on linux with threads either ( or not as you would
expect.... the main thread intercepts all alarms).
>tried to use it to interrupt read() on a serial port, and that wasn't
>working. Neither did SIGINT or SIGTERM. The only way to get out of it
>was Ctrl->Break, which shuts down the whole process.
>
>Unless the Glib timer can interrupt a serial port read() call, I don't
>see any way to timeout a serial port input function on Win32.
>Unfortunately, that means I will probably need to steal one of the FC5
>boxes from the next room in order to get it to work.
Yeah, Glib should be able to do it with some "flagging magic". I don't
have an example offhand, but if you look at that perlmonks url, about
rolling your own event loop, you can see how it MIGHT be done :-)
......pseudo-code follows......
### filehandle watch
open (FH, "+> test.log") or warn "$!\n"; # simulate your socket
Glib::IO->add_watch (fileno 'FH', ['in'], \&watch_callback, 'FH', 1 );
$main_loop->run;
########################################
############################
sub watch_callback {
my ($fd, $condition, $fh) = @_;
if($flag){return 1} # test for timer flag
my @lines = <FH>;
print @lines;
# here you might regex the lines for Ack or Nack, and if found,
#launch a timer to set a flag after 3 seconds ( act as alarm)
my $timer = Glib::Timeout->add (3000, \&timer_callback, undef, 1 );
#always return TRUE to continue the callback
return 1;
}
Like I said it was just pseudo code, and I have to admit, it would
probably take a few hours of realtime testing scripts, to see how
the serial port socket actually behaves..... the devil is always in the
details.
Switching to a linux box would make things work better for sure, but
first I recommend checking out POE. It is an advanced event-loop system
that has alot of the bugs worked out.
There is a POE cookbook of examples online, and you may find
something close to your needs.
POE does offer alarms and signals.
http://poe.perl.org/?POE_Cookbook
zentara
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
| |
|
|
|
|
|