Conceptualizing Threading

[JonathanB]

I have a multi-access problem that I'm pretty sure needs to be solved
with threading, but I'm not sure how to do it. This will be my first
foray into threading, so I'm a little confused by all of the new
landscape. So, I'm going to lay out the problem I'm facing and if
someone could point me towards a good example of what I need to do,
that would be great. I read THE tutorial, and while it made since to
me in an esoteric sense, I'm not sure how to implement it.

I have a program which will be logging who took what orders. These
orders need to have sequential order numbers. SR001001, SR001002,
SR001003, etc. Problem is I'm not sure how many people will be
accessing this program at the same time. I thought about separating
the order number into its own file and the having a function open it,
read it, increment it, write it, and close it really quick to limit
the chance of two people pulling the same number. Then I heard found
threading.

So this sounds like a consumer/producer problem, right? So I think I
need to use a Queue to crank out quote numbers and have the users
connect to the queue to get their number. Does that mean I'm looking
at two separate programs, a server and a client? Where do I separate
the programs? I was just about to give up and have quote number
assignment be manual (with error checking), but I thought I should
check here first and see if someone could help me wrap my brain around
this problem. You'll never learn if you never try, right?

 

[JonathanB]

You described how threads introduce a problem in your program -- that of
generating a sequence of sequential identifiers -- but you didn't describe
the problem that threads are solving in your program. Maybe you don't
need them at all? What led you to threading in the first place?

Jean-Paul

Well, the problem I thought they would solve is ensuring everyone got
a sequential number. But I suppose they wouldn't solve that, since
from what I gather thread access is somewhat arbitrary. So then, here
is the crux of the issue. Worst case scenario, this program could be
accessed by 5-10 people at a time and I need each one to have the
current information. There are two places I know of that there might
be multi-access problems.

1) This program is so that we can track one team passing assignments
to another. Right now I have the names of everyone in team 2 in a
list. People from team one launch this program and the program grabs a
pointer (stored in a separate file). If person A launches the program
and person B launches the program before person A assigns an order,
they will both have the same pointer, so both orders will go to the
same person.

2) Each assignment has a distinct identifier, which increments by 1
for each assignment (SR001001, SR001002, etc). Either these can be
assigned manually (the current method), or they can be assigned
automatically. If they are assigned manually, I need a way to show
them the most recent number (that would be easy), if they are assigned
automatically I need a way to save the number and pass the incremented
number along (just like the pointer). But I have the same problem here
as above. If two people launch the program at roughly the same time,
they will pull the same data. Since these assignments tend to come in
spurts, concurrent access is likely to be a problem.

So, given those parameters (the rest of this program is a breeze,
there's a class for each person on Team 2 and the class holds some
info about them and a dictionary of assignments with the assignment
number for the key and a value of [assigner, numberAssigned], the only
other tricky thing for me has been logging because I've never had to
do much of it before), how can I prevent these problems? The only
thing that jumps out at me is a server/client model where a server
runs and compiles all the entries, spitting back the result to each
individual client. That way, all the working code lives in the server,
ensuring that the working thread always has the right information,
while the clients only pass data between the user and the server. But
I guess that isn't technically multi-threading is it.

 

[Larry Bates]

I have a multi-access problem that I'm pretty sure needs to be solved
with threading, but I'm not sure how to do it. This will be my first
foray into threading, so I'm a little confused by all of the new
landscape. So, I'm going to lay out the problem I'm facing and if
someone could point me towards a good example of what I need to do,
that would be great. I read THE tutorial, and while it made since to
me in an esoteric sense, I'm not sure how to implement it.

I have a program which will be logging who took what orders. These
orders need to have sequential order numbers. SR001001, SR001002,
SR001003, etc. Problem is I'm not sure how many people will be
accessing this program at the same time. I thought about separating
the order number into its own file and the having a function open it,
read it, increment it, write it, and close it really quick to limit
the chance of two people pulling the same number. Then I heard found
threading.

So this sounds like a consumer/producer problem, right? So I think I
need to use a Queue to crank out quote numbers and have the users
connect to the queue to get their number. Does that mean I'm looking
at two separate programs, a server and a client? Where do I separate
the programs? I was just about to give up and have quote number
assignment be manual (with error checking), but I thought I should
check here first and see if someone could help me wrap my brain around
this problem. You'll never learn if you never try, right?

Just use a database with an auto-incrementing column. It will handle all
the "threading" that you think you require and each call will return the next
number you need.

-Larry

 

[Dennis Lee Bieber]

Well, the problem I thought they would solve is ensuring everyone got
a sequential number. But I suppose they wouldn't solve that, since
from what I gather thread access is somewhat arbitrary. So then, here
is the crux of the issue. Worst case scenario, this program could be
accessed by 5-10 people at a time and I need each one to have the
current information. There are two places I know of that there might
be multi-access problems.

You need to expand on "accessed by ..."

Do you mean 5 to 10 separate invocations of the program, each user
running the program on their machine in a stand-alone fashion -- or do
you mean one program invocation accepting 5 to 10 concurrent connections
by users.

In the first situation, threading won't help as threads operate
within a program image; you'd need a separate process running somewhere
that handles issuing ID numbers.

In the second, spawning a thread for each connection is viable --
and the ID number could be generated and passed to the thread during
creation. In this mode, the program is acting as a server -- you'll need
some sort of client (maybe a web browser?). If, instead of creating a
user thread on each connection, you maintain a pool of user threads
which just wait for a "go" signal, you could probably use a simple
function with a lock to block overlapping access.

So, given those parameters (the rest of this program is a breeze,
there's a class for each person on Team 2 and the class holds some
info about them and a dictionary of assignments with the assignment
number for the key and a value of [assigner, numberAssigned], the only
other tricky thing for me has been logging because I've never had to
do much of it before), how can I prevent these problems? The only
thing that jumps out at me is a server/client model where a server
runs and compiles all the entries, spitting back the result to each
individual client. That way, all the working code lives in the server,
ensuring that the working thread always has the right information,
while the clients only pass data between the user and the server. But
I guess that isn't technically multi-threading is it.

Okay... You are talking individual invocations...

Have you looked into some lightweight database server? (probably not
SQLite -- that's a "file server" database, as is M$ JET; you want a true
client/server). A decent database should have some means of generating
auto-increment numbers on inserts, and some way to retrieve the ID, and
using transaction locking should ensure that each client retrieves /its/
ID.

Uhmm... "... assignment number for the key and a value of [assigner,
numberAssigned] ..." sounds a bit redundant -- the key is part of the
value?

I still think I'd look at using a relational database; would allow
for easier changing of the lists of each group, etc. Start a
transaction, select next free person (I'm hypothesizing here), update
that person with an "assigned" flag, insert the person into the
assignments table (auto-generating a new ID), retrieve the "last insert
ID", commit transaction... return the ID to client for subsequent
processing.

Note: if, for some reason, you perform a rollback on the
transaction, that ID number could be lost forever -- many DBMS can't
revert autoincrement sequences... If a second transaction came in and
performed an insert after the first one, it may have the next higher
number, and a rollback of the first will now leave a gap in numbers. You
pretty much can not enforce a true sequential numbering without forcing
all users into a single line (client one connects, clients 2-10 get
"busy, try again later"). As soon as you allow concurrent connections,
the best you can do is insure /unique/ keys from a sequentially issued
list -- but those unique keys may be returned to clients "out of
sequence" just due to thread/process swapping and network latency.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/