That's why mutexes exist.
From an earlier AM post:
Because no replica is ever modified or seen by another thread as its own, no locking is necessary.
I accept that with the addition of a concept of ownership (implemented through "take ownership" & "release ownership" messages; or several otherways) that the meshanisms described in the RFC could become the basis for a inter-thread, data-sharing mechanism.
It's not to dissimilar from the message passing semantics of Win32/OS-2/other GUIs, or even those of SmallTalk.
However, you'll (I hope) accept that this is:
And your problem with incrementing shared values isn't new,it's in every threading library.
It's not just incrementing an integer. Any form of modification to an existing value suffers the same problem of requiring synchronisation and locking. Appending to ...; upper/lower-casing ...; truncating a string. Indeed anything that you might do with s/// rather than m// woulld require this. Along with any math; anything that modified the state of a object; and so on.
Perhaps my mistake was to take the idea that you (or some Anonymous Monk?*) seriously.
* With the first quote in my sig, it would be crass to critique you for corresponding anonymously, but it does make life a life a little more tolorable to know you are continuing a conversation with a single individual, and not just another passer-by making comment on the basis of one post, rather than the complete thread. Maybe we should have a set of AM1..N anonymonk ID's that could be "occupied" for the duration of single conversations--but then how would you indicate that you are the same person without some form of verification? Oh well! Continuing, assuming you are the same AM.
It all comes back to your(?) response to my assertion:
If it was trivial, or even if it was possible with a reasonable degree of difficulty to coordinate and synchronise objects across threads, Perl would do that for you. The fact that the clever guys that got iThreads this far did not step up to the plate and do this already, almost certainly means that you should not be trying to do this either.
Namely:
Yes it's easy to synchronize objects (at least Storable ones) across threads. RFC677 (yes the one from IETF) tells you how.
Once you accept the premise that to do anything useful with shared objects across threads, you need to be able to share and modify the internal state of that object from all sharing threads, you need to implement locking somehow--as opposed to what the OP of this thread later admitted he was doing which is to use Storable to pass a pre-initialised object to a thread for instantiation within that thread; and for it's exclusive use--you can then look at how you might easily implement that.
Assuming that you got past that last overcomplicated sentance/paragraph in agreement, then I would suggest that in a threaded environment, where the basis merit is that you have shared access to memory, that duplicating data is entirely the wrong way to go about it. Once you employ the message passing semantics to all accesses to the internals of an object, there presents itself a much cleaner, less memory intensive solution to the problem.
Rather than duplicating all the data(attributes) and all the methods to every thread sharing access; you maintain a single copy of all shared objects (data and methods) in a single thread's memory space, and an object reference becomes a handle that identifies:
Any operation (method call) on a shared object then gets translated into a message enqueued to the owning thread identifying the object(instance); the method called; and the parameters. The "calling thread" blocks until the sharing thread processes the message and returns the result.
The advantages of this mechanism are:
These non-shared operations continue at full speed.
The key to this statement is that "sending the message" to the sharing thread, would in fact suspend the sending thread, and co-operatively transfer it's timeslice(s) to the sharing thread. And the key to that is a little known Win32 mechanism called Fibres.
For some stupid reason, the only MSDN/Fibres link that google will throw up right now is a French language page. I'll try to update with the English version once Google/MSDN is being more cooperative.
Now I doubt if the concept is unique to win32, but I don't actually know of another implementation, so I can't discuss it in generic terms.
The basic description is this. You create a pair (or more) threads in the usual way, but then you "convert" them into a fibres. Once this is done, the two fibres share a single thread's timeslices' cooperatively, within the auspices of the overall pre-emptive multi-tasking environment. They, in effect, become timesliced co-routines.
The full implications and advantages of this arrangement aren't entirely obvious when you first read the descriptions of them, but with thought, the possibilities are quite fascinating.
Many languages feel the need to implement their own (usually cooperative) threading internally (Java etc.), in order to make sharing objects across threads feasible. The disadvantage of this is that each "thread" within a process shares a single OS timeslice--because the Process is doing the timeslicing. This is especially disadvantageous in a multi-processor SMP-type environment as it precludes making full (any?) use of multiple cpu's within a single process. Fibres do not suffer this restriction as they are first-class OS level objects, not language-based, per-process objects.
My thoughts on this are not fully formed yet. My progress on implementing the ideas I'm trying to describe here (which first came to me about 9 months ago--and as far as my searches for prior art have gone, are unique?) is slow.
To implement the ideas requires using a language that allows low-level access to the machine.
C would work, but then you get
POSIX-complient libraries, then nearest thing to cross platform available simply don't cover the ground that I'm experimenting in;
Objects, vtables, references, memory management, exception handling, etc.
C++ is possible, but has
Java.
Perl. Obviously not!
There are two choices: (macro) assembler. Hard work. cpu if not OS specific.
My choice: D. Has (or will have) everything I want and nothing I don't. Already cross-platform after a fashion, and getting stronger. The downside is that it's still going through birthing pains.
One day I'll have something to show for my thoughts, efforts and research that will justify some of my expressed opinions. Till then, all I can do is express them and consider each alternative and counter argument in the light of what I already (think) I know.
In reply to Re^9: Passing globs between threads (Updated).
by BrowserUk
in thread Passing globs between threads
by conrad
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |