Subj : Re: Lockable objects
To   : comp.programming.threads
From : doug
Date : Thu May 19 2005 07:37 pm


"Sergei Organov" <osv@javad.ru> wrote in message 
news:d6iims$pug$1@n6.co.ru...
> "Uenal Mutlu" <520001085531-0001@t-online.de> writes:
>> A mutex can be realized in just 8 bytes (counter and threadid).
>> These methods would be like any other method of the object:
>> just use which you want/need/like, or don't use at all: you have the
>> choice.
>
> Didn't you forget to attach a condvar to every non-trivial object as
> well? Just imagine how useful it is to have it ready for signalling and
> for waiting for changes to the object!
>
>> The advantage of having such an "architecture" in the language
>> gives far more possibilities for the users.
>
> ... and then we end up with a "class Everything" that provides all the
> imaginable possibilities to the user, including automated check against
> famous Uenal Mutlu deadlock theorem. We have reached ultimate
> perfectness! Congratulations! The only problem is that it seems that
> nobody but Uenal Mutlu will use the language then.
>
>> And: multithreading has become a de facto standard in programming,
>> esp. in application programming.
>
> ... mostly due to the fact that one famous OS doesn't provide a sensible
> way to deal with non-trivial IO without threads and has pure support for
> processes, IMHO. Hard times during which programmers learn *not to use
> threads* where they are inappropriate I foresee :(
>
> -- 
> Sergei.

I imagine someone's just finished the latest chapter in their threading 
book.  However, it doesn't look like he's actually *ready*, just skimming.

So here's some random babbling.  I don't see why i should bother to 
formulate my points properly, if a) you don't respond to them, and b) your 
postings aren't just random, their plain nonsense!
- why 8 bytes?  Is that just because that's what your current OS uses?  what 
about other systems?  what about things like alignment?  especially on SMP 
systems?
- counter and thread id.  Didn't you forget the actual lock itself?
- what use is GetLockedCount() or IsLocked()?  (Unless it's for 
debugging/diagnostics).  When called by the non-owner, they're unreliable, 
and there's no reason an owner should need to call these.  Providing them 
just promotes extremely poor design.
- what about timed acquires?
- you've forgotten about signal semaphores/condition variables.  It's likely 
you don't know what these are.
- what about single-writer, multi-read locks?
- finally, recursive mutexes.  No, no, no, no, no.  Especially, with 
multi-cores becoming common, if you write multi-threaded programs, a 
recursive lock (as others have pointed out to you), serves one and only one 
purpose - the ability to put a bottleneck in your program.  (Maybe two - the 
abliity to hide bugs until your customer runs the code.)

.