On Jul 25, 2:50 am, llothar <llot...@[EMAIL PROTECTED]
> wrote:
> On 25 Jul., 13:10, lee <cogn...@[EMAIL PROTECTED]
> wrote:
>
> > Is this your understanding of lock-free or did I miss something? Let
> > me know and then I can give you my 2 cents on how some of these ideas
might
> > be achieved with SmartEiffel 2.3.
>
> Yes this was exactly what i meant.
Lothar,
Here is a conceptual view of how to implement multi-threading with
smarteiffel. Now that I have seen the definition of lock-free (which
you provided the impetus for), I think this approach can be lock-free
and possibly wait-free. First, some assumptions:
1. Data locking is omitted in the following ways:
(a) Each thread has its own data source.
(b) If threads need data from the same source (e.g., a database), the
developer has to ensure that the data is segmented into independent
segments.
2. Inter-thread communication will be necessary:
(a) I assume that threads will have to communicate (e.g., status,
status change commands, and exceptions)
(b) This avenue will also provide a means to control a thread's
execution (e.g. to send a "sleep" or "kill" command).
First, I would define a transaction server that can execute
transactions (of course).
These transactions would make use of the "sequencer" library of SE in
order to possibly use some of those features (e.g. - priority, prepare
procedure, is_ready function, etc.)
Then, the server would execute a JOB (a SE class) from the server's
LOOP_STACK.
The examples/tutorial mentions that these jobs are executed in
parallel, but I could not see the mechanism for that. By parallel, I
assume that the SE developers meant simultaneously, but they could
have also meant that as one job finished, another job starts, which
would mean sequentially.
If this is the case, then I would use the PROCESS_SCHEDULER class to
launch an exec. The notes say that following about the PROCESS
class: "This class is in a beta stage. POSIX and Windows versions are
available but there may be resource leaks or other bugs left."
Even though the PROCESS class is "experimental," the inter-thread
communications would provide a way to implement threading control.
Now, I understand that on Windows and some Unixes (i.e., not Linux),
threads are more lightweight than processes. So using a process may
involve additional memory, etc., which you already mentioned as a
liability of threads. My understanding of Linux is that the kernel
makes very little distinction between threads and processes so that
you do not have the overhead issue involved in creating a process
instead of a thread.
While this is not a complete technical description, it should give you
enough information to ask me some questions or to critique it. Please
let me know.
Lee
|
