DrunkenBlog

 Posted by: sevilla at February 1, 2005 12:27 PM

I'm more confused after reading through that interview. Sometimes I wish they would give some real world examples... who can understand that stuff? My organic chemistry textbook is easier to get through.

 Posted by: Kint at February 1, 2005 01:17 PM

I can resume the whole thing in one phrase;

"I hard encoded the transistor gigaflop switch to the analogue Proteus nord rack 2 Quasimidi ray diode."

 Posted by: caller caller at February 1, 2005 02:30 PM

quoting from the links:

The consequence of this model is that a subsystem can obtain a token and hold it while performing potentially complex calls into other subsystems without having to inform those other subsystems that it is holding the token. The caller still has to be aware that the subsystem might block, thereby temproarily breaking the serialization the token provides, but this matters only for a small portion of the token use in the system and still isolates the knowledge to the caller (i.e. if it isn't sure it must assume that a call into another subsystem might block).

What the hell does that SAY? (puts on tinfoil hat) I think you linked to it to make how you explain things look good. Well it worked lol (takes off tinfoil hat)

 Posted by: David Magda at February 1, 2005 07:15 PM

The consequence of this model is that a subsystem can obtain a token and hold it while performing potentially complex calls into other subsystems without having to inform those other subsystems that it is holding the token.

Normally when you get a lock / mutex for multi-threading for one subsystem (network), you have to release it if you enter another subsystem (file system). So the pseudo-code would be:

get_network_lock()
do_some_netowrk_stuff()
release_netowrk_lock()

get_fs_lock()

do_fs_stuff()

release_fs_lock()

get_network_lock()

...

If you go into the file system subsystem with the "network" lock, and the file system somehow delays your program, no other program can get the network lock. So your program is stalled because of something in the FS, but all other programs that using the netowrk lock are also stalled because they're waiting for your program to release the network lock.

What DBSD's system does (will do?) is keep track of of the tokens. So you can keep the network token ("lock"), go into the FS subsystem with it, and it won't stall other programs.

At least that's my understanding of it.