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


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d6itn1$4sg$01$1@news.t-online.com...
> "doug" wrote
>>
>> "Sergei Organov"  wrote in message
>> > "Uenal Mutlu" 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.)
>
> Are these questions directed to me?
>
>
Also, I'd be interested in your response to the post in Challenge: 
Multithreading & Synchronization - the one where I reply to you about your 
'Case 2' being broken.

Off to the pub!

.