sponge45 changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/
shawn has joined #ocaml
smimou has quit ["bli"]
tsuyoshi has quit ["Lost terminal"]
tsuyoshi has joined #ocaml
mbishop has quit [Remote closed the connection]
danly has quit [Read error: 60 (Operation timed out)]
m3ga has joined #ocaml
danly has joined #ocaml
slowriot has quit []
danly_ has joined #ocaml
danly has quit [Read error: 110 (Connection timed out)]
pango has quit [Remote closed the connection]
pango has joined #ocaml
b00t has joined #ocaml
Smerdyakov has quit ["Leaving"]
shans__ is now known as shans
bzzbzz has quit ["leaving"]
mbishop has joined #ocaml
shawn has quit [Read error: 110 (Connection timed out)]
pants1 has joined #ocaml
johnnowak has quit []
b00t has quit [Read error: 104 (Connection reset by peer)]
b00t has joined #ocaml
Skal has joined #ocaml
Skal has quit [Remote closed the connection]
Skal has joined #ocaml
Mr_Awesome has quit ["and the Awesome Level drops"]
pants1 has quit ["Leaving."]
jlouis has quit [Remote closed the connection]
shawn has joined #ocaml
_velco has joined #ocaml
m3ga has quit ["disappearing into the sunset"]
pango has quit ["Client exiting"]
delamon has joined #ocaml
love-pingoo has joined #ocaml
pango has joined #ocaml
smimou has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
smimou has quit ["bli"]
love-pingoo has quit ["Connection reset by pear"]
gaja has quit [Remote closed the connection]
love-pingoo has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
<dark_light>
if I use mutex for protecting shared data structures, I should lock at every access at the structure or only when modifying the structure? I am unsure
<ulfdoz>
Depends on needs. Often it is enough to lock on modification, sometimes, constraints are harder to prevent errornous reads.
<dark_light>
i am not sure what is my needs
<ulfdoz>
I can't tell you. When in doubt, use the stricter requirement.
<ulfdoz>
essentially, this means to lock on every access and possibly to define a strict order of accesses.
<ulfdoz>
The advantage of this approach is, that it is easy to implement, because you need not to distinguish between read and write.
<dark_light>
i was using events to handle this, but the approach was very confuse to me, i think i am using it wrong
<dark_light>
ulfdoz, actually i do not really know why mutexes are needed for me. ocaml can't really execute two things at once and i am using only atomic operations (like sharedstructure.field <- newvalue)
<dark_light>
... i am quite confused :D
<ulfdoz>
dark_light: The problems arise, when one thread is interrupted between a read and write and another thread modifies the shared structure.
<dark_light>
i gave a vacation to this code (because it's becoming very annoying) but when i returned to it, i am unsure what i should do
<dark_light>
ulfdoz, in that case, i should lock before the read and unlock after the write, right?
<ulfdoz>
dark_light: Yes.
<ulfdoz>
and the lock-operation must be atomic.
<dark_light>
i am unsure if i will ever have a situation like that
<dark_light>
i am working in a thing like this: http://nopaste.llamah.org/140 , i think these locks are really unecessary for the operations i defined in let change_player ..
<ulfdoz>
I'd keep it, for correctness, at least it is not much overhead.
<dark_light>
hmmmm...
<dark_light>
but if i need to do this for reading too, there is no point in mantaining a record (i am using a shared record just to easly do player.name ..)
<ulfdoz>
Im currently thinking about, whether the locking is done in the right place. Assume you have a player value and two threads concurrently changing the player-structure. Are you sure the values are consistent afterwards?
love-pingoo has quit ["Leaving"]
<ulfdoz>
i.e. I think, it is typical, that several fields of the player structure are changed at once, which would be several operations, which can interleave, when having different threads.
<dark_light>
ulfdoz, i created a example where i have a shared record with x and y values and thread A were changing only the x field, and thread Y changing only y, it seemed that i need no lock in that case
<dark_light>
ah
<dark_light>
hmmm
<dark_light>
several fields changed at once?
<dark_light>
Hmmmmmmmmm maybe i need something like a.. "nonatomic_change" that locks the entire player and executes a list of changes
<ulfdoz>
For example: If you change the field player.name, than the field player.title is likely to be changed in near future, too.
<dark_light>
hmm i understand your point
<dark_light>
but, i need to lock while reading too? :( eg: if i am changing name and title, i need to lock while reading the name? or: i need to lock while reading the access?
<dark_light>
i am thinking i will never need to lock while reading (that is what i want to believe, for my own sanity:)
<ulfdoz>
I'd lock the whole structure to prohibit modification until the read is finished.
<ulfdoz>
Imho, most often it is not necessary, to limit the number of concurrent reads, but as long as any read is in progress, no modification should be done.
<dark_light>
it's like.. i will read A and B, and i want a consistent value of A and B, but if someone change B and then A, i can read the old A and the new B, and i am with inconsistent data?
<ulfdoz>
yes.
<dark_light>
i give up of shared structures.
<dark_light>
:(
<dark_light>
maybe with events i will be happy.. then :(
<dark_light>
my current code has a channel that hears for things like Db_list_players of player list Event.channel
<dark_light>
and the db thread read the event, and reply with a list of players
<dark_light>
that isn't very intersting because the players has mutable fields
<dark_light>
ulfdoz, you think it's ok to have a database thread that blocks while doing every operation?
<dark_light>
i wanted to make the calling threads do the operations to ensure that the db will be free, but it's beginning to become impossible
<ulfdoz>
dark_light: For best performance I'd do non-blocking reads and blocking writes. The most complicated thing left to implement is the scheduling of the reads/writes. ;)
<dark_light>
it's too stupid creating a new thread every read?
b00t has quit [Remote closed the connection]
<dark_light>
well, for the time i will make blocking reads
Submarine has joined #ocaml
<delamon>
ulfdoz: and how do you managed shedule them?
<ulfdoz>
delamon: Usually, I allow reading, until a write-request is triggered, then I wait until all reads are finished. After this, I do the actual write lock, the write and finally unlock the structure.
Skal has quit [Remote closed the connection]
Submarine has quit [Remote closed the connection]
ikaros has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
klapmuet1 has joined #ocaml
klapmuetz has quit [Read error: 60 (Operation timed out)]
Smerdyakov has joined #ocaml
metaperl has joined #ocaml
<metaperl>
does Ocaml's oo mesh well with its functional core?
<Smerdyakov>
Yes. The OO system has some fundamentally imperative features, but it's easy to avoid them systematically.
<dark_light>
methods can be treated as functions, if it's what you asked metaperl
<metaperl>
i see - there was a huge war (and still is) in #haskell - the author of Factor is there because someone started railing on it