http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* HELP - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/a863d4f1119976f8?hl=en
* Library requirement for mutex destroy - 6 messages, 4 authors
http://groups.google.com/group/comp.programming.threads/t/4a94e9df8d2f3e22?hl=en
* Mechanism for interrupting a task sleeping on a lock - 3 messages, 3 authors
http://groups.google.com/group/comp.programming.threads/t/6e694636e3ed2644?hl=en
==============================================================================
TOPIC: HELP
http://groups.google.com/group/comp.programming.threads/t/a863d4f1119976f8?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Oct 31 2009 1:23 pm
From: kennethadammiller
For those that want to say that I ask to much rather than look things
up myself... well, sorry. I've researched really hard, but I feel
like the information is between the lines, and I need someone who
knows. It will be much harder to go research this without asking
somebody, costly in time that is. And besides that's what these groups
are for right?
Before my 9.10 install, which went well, I was using an old version of
eclipse that I had added from the add/remove to make some programs. I
needed Visual Editor to make some things and when I tried to install
it, it kept giving me some null pointer exception or pointer not found
exception. I had to go post an error log and get on ubuntu irc channel
to find out that I need to be using a different Virtual machine for
eclipse and that I needed to update eclipse. well I upgraded my distro
and found that when I added eclipse from the add/remove, it wouldn't
let me add the visual editor either. I removed it and then added it to
my system following these instructions-
http://johnpaulett.com/2009/06/26/install-eclipse-galileo-3-5-on-ubuntu-jaunty/
So i left VE alone and started to import my old source files, and I
kept getting some error any time I tried to test run that I couldn't
find the main class. I tried copying everything from the workspace to
my desktop to back it up, so I could systematically delete the
projects and recreate them. This still kept coming up with errors.
Through all of this I am facing numerous related issues. I really need
advice.
Things I would like answered from curiousity...
Should I even still use eclipse?
why did the people who manage the add/remove not update the eclipse
thing to say something or have a recent edition? (and who manages the
add/remove in the first place?)
why is there more than one type of VM?
What is the difference between J2SE and J2EE? (i know what the letters
stand for...)
The most important part though is the issues:
I still need VE for eclipse. it won't add. I don't know why.
Sometimes when I click a button, in any dialog of eclipse (the actual
editor's dialog panes that is), the buttons go down, but do nothing.
this is causing a lot of problems
How do I install the VM that is compatible with eclipse? If I do this,
what will happen to the one that netbeans uses, if I should decide to
use netbeans?
Guys thanks a lot.
And anyone that wants to can check out my program when I'm finished.
it's going to be really cool :):)
I'm nearly done, as soon as I get these problems out of the way, I can
get back to work on it. Thanks in advance, and let me know if you're
interested.
Program information: http://uberprogrammer.blogspot.com/2009/10/project-dirscourrec.html
==============================================================================
TOPIC: Library requirement for mutex destroy
http://groups.google.com/group/comp.programming.threads/t/4a94e9df8d2f3e22?hl=en
==============================================================================
== 1 of 6 ==
Date: Sun, Nov 1 2009 1:37 am
From: Rainer Weikusat
frege <gottlobfrege@gmail.com> writes:
> On Oct 28, 9:27 am, Noob <r...@127.0.0.1> wrote:
>> [ Cross-posted to c.p.t and c.u.p ]
[...]
>> But this library has specific requirements for the delete function:
>>
>> If delete is called on a locked mutex, the function must return an error
>> code to signal the error to the function's caller.
[...]
> I basically agree with everyone else - the specs are stupid. But my 2
> cents anyhow:
>
> 1. just don't implement it, but say you did. ie have delete never
> return an error. The error would only ever been seen in broken code
> anyhow.
I consider it likely that the library was implemented by someone
familiar with (and only with) the Windows threading interfaces,
because these happen to have a couple of the properties David Schwartz
mentionend, especially, that it is impossible to declare 'mutex'
objects residing in memory accessible to all and therefore,
indiscriminately usable by all threads. A Windows mutex is a
system-managed object and can only be used by threads which happen to
have a copy of the handle. Further, there doesn't seem to be a trylock
operation and I am fairly convinced that the CloseHandle function
will detect an attempt to release a locked mutex and notify the caller
of that (I could be wrong on all the details, though), since this
would be in line with the 'child-safety precaution at any cost'-mindset
which is so common among everything sprung from Redmond. Because of
this, I assume that the library uses 'delete' to emulate 'trylock' and
if this was true, your suggestion above would certainly not be a
helpful one.
== 2 of 6 ==
Date: Sun, Nov 1 2009 8:45 am
From: Eric Sosman
Rainer Weikusat wrote:
> frege <gottlobfrege@gmail.com> writes:
>> On Oct 28, 9:27 am, Noob <r...@127.0.0.1> wrote:
>>> [ Cross-posted to c.p.t and c.u.p ]
>
> [...]
>
>>> But this library has specific requirements for the delete function:
>>>
>>> If delete is called on a locked mutex, the function must return an error
>>> code to signal the error to the function's caller.
>
> [...]
>
>> I basically agree with everyone else - the specs are stupid. But my 2
>> cents anyhow:
>>
>> 1. just don't implement it, but say you did. ie have delete never
>> return an error. The error would only ever been seen in broken code
>> anyhow.
>
> I consider it likely that the library was implemented by someone
> familiar with (and only with) the Windows threading interfaces,
> because these happen to have a couple of the properties David Schwartz
> mentionend, especially, that it is impossible to declare 'mutex'
> objects residing in memory accessible to all and therefore,
> indiscriminately usable by all threads. A Windows mutex is a
> system-managed object and can only be used by threads which happen to
> have a copy of the handle. Further, there doesn't seem to be a trylock
> operation and I am fairly convinced that the CloseHandle function
> will detect an attempt to release a locked mutex and notify the caller
> of that (I could be wrong on all the details, though), since this
> would be in line with the 'child-safety precaution at any cost'-mindset
> which is so common among everything sprung from Redmond. Because of
> this, I assume that the library uses 'delete' to emulate 'trylock' and
> if this was true, your suggestion above would certainly not be a
> helpful one.
You may be right about the Windows origin of the nonsense
specification, but I still cannot understand how a delete
could be used in a trylock emulation. If you delete the mutex
and are told "No, it's locked," fine: Your pseudo-trylock can
report that the mutex was locked and hence not acquirable.[*]
But what if the deletion succeeds? You then know that the
mutex wasn't locked, but what good does it do you? You can't
now lock it, because it no longer exists. (Any any other
thread that was about to lock it -- or delete it -- is in
deep trouble, too.)
[*] Actually, not even this much is true. The O.P. said
the mutexes were supposed to be recursively lockable, so a
mutex that is locked and hence not deletable might have been
locked by the same thread, and hence acquirable despite the
deletion failure.
--
Eric Sosman
esosman@ieee-dot-org.invalid
== 3 of 6 ==
Date: Sun, Nov 1 2009 10:15 am
From: Rainer Weikusat
Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> Rainer Weikusat wrote:
>> frege <gottlobfrege@gmail.com> writes:
>>> On Oct 28, 9:27 am, Noob <r...@127.0.0.1> wrote:
>>>> [ Cross-posted to c.p.t and c.u.p ]
>>
>> [...]
>>
>>>> But this library has specific requirements for the delete function:
>>>>
>>>> If delete is called on a locked mutex, the function must return an error
>>>> code to signal the error to the function's caller.
[...]
>> Further, there doesn't seem to be a trylock
>> operation and I am fairly convinced that the CloseHandle function
>> will detect an attempt to release a locked mutex and notify the caller
>> of that
[...]
>> I assume that the library uses 'delete' to emulate 'trylock'
[...]
> You may be right about the Windows origin of the nonsense
> specification, but I still cannot understand how a delete
> could be used in a trylock emulation. If you delete the mutex
> and are told "No, it's locked," fine: Your pseudo-trylock can
> report that the mutex was locked and hence not acquirable.[*]
> But what if the deletion succeeds? You then know that the
> mutex wasn't locked, but what good does it do you?
> You can't now lock it, because it no longer exists.
If it is now impossible to lock the mutex which no longer
exists, the intent was quite obviously not to lock the mutex, only to
determine that a particular thread has unlocked a particular mutex,
presumably, after having completed some related task.
> (Any any other thread that was about to lock it -- or delete it --
> is in deep trouble, too.)
As obviously, no such 'other thread' may exist.
> [*] Actually, not even this much is true. The O.P. said
> the mutexes were supposed to be recursively lockable, so a
> mutex that is locked and hence not deletable might have been
> locked by the same thread, and hence acquirable despite the
> deletion failure.
Something which obviously doesn't make sense might simply be
wrong. As I wrote in the first paragraph: Since 'destruction of the
mutex' is a side effect of such a probe-operation, acquiring said
mutex can't be the objective. Determining information about a
particular mutex (and consequently, the state of a particular thread)
could.
== 4 of 6 ==
Date: Sun, Nov 1 2009 12:20 pm
From: David Schwartz
On Nov 1, 10:15 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> If it is now impossible to lock the mutex which no longer
> exists, the intent was quite obviously not to lock the mutex, only to
> determine that a particular thread has unlocked a particular mutex,
> presumably, after having completed some related task.
Or before having started some related task. And if you have some kind
of synchronization other than the mutex that tells you the thread has
started the task, why wouldn't that same method tell you when it had
finished that task?
My bet is someone just took whatever ratbag assortment of feature
there platform's mutexes happened to have, or that they thought their
platform had due to misunderstandings and confusions of various sorts,
and asked for that.
DS
== 5 of 6 ==
Date: Sun, Nov 1 2009 12:59 pm
From: Eric Sosman
Rainer Weikusat wrote:
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>
>> Rainer Weikusat wrote:
>>> [...]
>>> I assume that the library uses 'delete' to emulate 'trylock'
>
> [...]
>
>> You may be right about the Windows origin of the nonsense
>> specification, but I still cannot understand how a delete
>> could be used in a trylock emulation. If you delete the mutex
>> and are told "No, it's locked," fine: Your pseudo-trylock can
>> report that the mutex was locked and hence not acquirable.[*]
>> But what if the deletion succeeds? You then know that the
>> mutex wasn't locked, but what good does it do you?
>> You can't now lock it, because it no longer exists.
>
> If it is now impossible to lock the mutex which no longer
> exists, the intent was quite obviously not to lock the mutex, only to
> determine that a particular thread has unlocked a particular mutex,
> presumably, after having completed some related task.
In what sense does that "emulate `trylock'?"
>> (Any any other thread that was about to lock it -- or delete it --
>> is in deep trouble, too.)
>
> As obviously, no such 'other thread' may exist.
If it is possible that the delete operation finds the
mutex locked, it follows that some thread somewhere has a
reference to the mutex. (Or "had" a reference to the mutex,
locked it, and then leaked the reference, in which case the
mutex can never be unlocked or deleted by anybody, ever.)
If a thread other than the deleter has a reference to
the mutex, that thread might use the reference to attempt a
lock or delete or other operation (if there are any in this
library). There is no way inherent in the mutex to prevent
the other thread from making use of its reference. There
are other ways (program conventions or protocols) to do so,
but if it is possible for delete to find the mutex locked,
it is clear that no such protocols are operating.
If the deleting thread is the only holder of a reference
and finds the mutex locked, either the deleter itself holds
the lock or the the thread that locked it has leaked its
reference as described above. If the deleter holds the lock
it is just barely possible that the operation might make sense,
but it can't be a trylock emulation (because it never acquires
the mutex, not even when the mutex is available).
> Something which obviously doesn't make sense might simply be
> wrong. As I wrote in the first paragraph: Since 'destruction of the
> mutex' is a side effect of such a probe-operation, acquiring said
> mutex can't be the objective.
That is, it's *not* a trylock emulation.
> Determining information about a
> particular mutex (and consequently, the state of a particular thread)
> could.
Determining what the state of affairs looked like one CPU
cycle ago might be interesting for statistical purposes, but
for nothing else. A destructive determination isn't good even
for that much.
--
Eric Sosman
esosman@ieee-dot-org.invalid
== 6 of 6 ==
Date: Sun, Nov 1 2009 1:01 pm
From: Måns Rullgård
David Schwartz <davids@webmaster.com> writes:
> On Nov 1, 10:15 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
>> If it is now impossible to lock the mutex which no longer
>> exists, the intent was quite obviously not to lock the mutex, only to
>> determine that a particular thread has unlocked a particular mutex,
>> presumably, after having completed some related task.
>
> Or before having started some related task. And if you have some kind
> of synchronization other than the mutex that tells you the thread has
> started the task, why wouldn't that same method tell you when it had
> finished that task?
>
> My bet is someone just took whatever ratbag assortment of feature
> there platform's mutexes happened to have, or that they thought their
> platform had due to misunderstandings and confusions of various sorts,
> and asked for that.
I'd be curious to know what this library is.
--
Måns Rullgård
mans@mansr.com
==============================================================================
TOPIC: Mechanism for interrupting a task sleeping on a lock
http://groups.google.com/group/comp.programming.threads/t/6e694636e3ed2644?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Nov 1 2009 5:17 am
From: Balban
Hi all,
In my kernel I have implemented an interruptible sleeping mutex. As a
sleeping mutex, it is similar to ones you would find in popular OS'es
where the task that could not acquire the lock goes to sleep until the
lock becomes available.
I have real-time priority concerns and would like to be able to
interrupt a sleeping task, when it is sleeping for whichever reason.
In that respect, I have implemented the mutexes as interruptible, such
that a thread that sleeps on a lock can be woken up for two reasons:
Either the lock is available, or it has been interrupted by someone
(e.g. its superior parent, or a high priority task)
With this mechanism, a thread who already took 2 such locks and has
slept on the third one, can interrupt, and upon interruption finish
gracefully, by releasing all its locks, leave all the data structures
in good state, and leave the kernel, to retry the operation later.
The problem is that *every* mutex in the system now has become
conditional, e.g. I need to check the return value on whether it has
been interrupted or not on every mutex_lock() operation. Is this the
best way to handle things or do you have a better suggestion?
In a nutshell the core of my problem is to be able to take control
over a data structure or a sleeping task, in case a higher priority
event occurs that relates to one of those entities.
Thanks,
Bahadir
== 2 of 3 ==
Date: Sun, Nov 1 2009 7:26 am
From: David Schwartz
On Nov 1, 5:17 am, Balban <bilgehan.bal...@gmail.com> wrote:
> In a nutshell the core of my problem is to be able to take control
> over a data structure or a sleeping task, in case a higher priority
> event occurs that relates to one of those entities.
I guess I don't understand what you're talking about. Consider:
Thread T1 acquires mutex M1, which protects data structure D1.
Thread T1 dirties data structure D1.
Thread T1 blocks for mutex M2, which protects data structure D2.
Thread T2, at higher priority, wants mutex M1 to access data structure
D1.
Are you saying that you want to interrupt thread T1's blocking on M2
and command it to release M1? That would require the thread "backing
out" whatever changes it made to D1.
If so, why put that in the mutex? Why not just code thread T1 and T2
to do exactly that in user-space with the existing threading
primitives? As you've noticed, trying to put it in the mutex
implementation creates all kinds of problems.
DS
== 3 of 3 ==
Date: Sun, Nov 1 2009 9:04 am
From: Marcel Müller
Hi,
Balban wrote:
> Either the lock is available, or it has been interrupted by someone
> (e.g. its superior parent, or a high priority task)
>
> With this mechanism, a thread who already took 2 such locks and has
> slept on the third one, can interrupt, and upon interruption finish
> gracefully, by releasing all its locks, leave all the data structures
> in good state, and leave the kernel, to retry the operation later.
hmm, waiting for a mutex at real time priority is tough. Waiting for
multiple mutexes even more.
> The problem is that *every* mutex in the system now has become
> conditional, e.g. I need to check the return value on whether it has
> been interrupted or not on every mutex_lock() operation. Is this the
> best way to handle things or do you have a better suggestion?
Use an OO language and throw an interrupted exception in case you want
to cancel a request. It is then up to the application code to catch the
exception at the appropriate level of stack unwinding. Of course, your
application code has to be exception safe for that to avoid resource
lacks and undefined behavior. But this is a good advise anyway.
> In a nutshell the core of my problem is to be able to take control
> over a data structure or a sleeping task, in case a higher priority
> event occurs that relates to one of those entities.
A classical priority inversion problem. I don't think that your
suggested solution is a good advise. But of course, I don't know your
demands.
Have a look for solutions of priority inversion problems.
Sometimes using lock-free data structures and algorithms is an option too.
You should avoid shared data and too much mutexes in real time
applications. Use controller threads with state machines and local data.
The different engines could communicate over command queues. They can be
lock-free primitive objects. If well designed the payload has never to
be passed through the command queues at all.
If this is not adequate use conditional variables to lock certain
actions and access these conditional variables partially atomic to avoid
mutex requests at critical code locations.
Marcel
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.
To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en
To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment